Re: Noise using pulseaudio with ymf724f

Re: Noise using pulseaudio with ymf724f

[Raymond Yau]

2011/9/12 Clemens Ladisch <clemens@ladisch.de>:
> Raymond Yau wrote:
>> How accurate is the ymfpci timer ?
>
> The period interrupts are not accurate at all.  The ymfpci hardware
> internally uses fixed periods of 256 frames at 48 kHz; the driver
> reports a period interrupt when the next hardware interrupt at or after
> a period boundary occurs.  The current position reported by the hardware
> is the position at the time of the last hardware interrupt.
>
>> my ymf724f seem play quite well with alsa "hw" device but with bad
>> noise with alsa-pulse plugin (e.g. aplay when not using default period
>> times )  and it also occurrs on   benshee on ubuntu 11.4 live cd
>
> It should be possible to increase accuracy by using the hardware period
> parameters (48 kHz _and_ 256 frames/period).
>
> TODO: implement support for the NORESAMPLE flag.
>
>

Is 256 frames/period in s16 stereo since the card support mono ,
stereo , U8 and S16 ,

What is the meaning of SNDRV_PCM_INFO_BLOCK_TRANSFER since the
rewind_safeguard of PA server is 256 bytes ?

Will this help since minimum period time of snd_ymfpci is 5.333ms but
alsa-pulse plugin announce a lower value 128 bytes (period_bytes_min)
to the alsa application ?

PA server has

#define ABSOLUTE_MIN_LATENCY (500)
#define ABSOLUTE_MAX_LATENCY (10*PA_USEC_PER_SEC)

Re: Noise using pulseaudio with ymf724f

[Clemens Ladisch]

Raymond Yau wrote:
> Is 256 frames/period in s16 stereo since the card support mono ,
> stereo , U8 and S16 ,

The hardware uses S16 stereo at 48 kHz internally; everything else is
converted and resampled to that.

> What is the meaning of SNDRV_PCM_INFO_BLOCK_TRANSFER

That the card transfers samples in blocks.

> since the rewind_safeguard of PA server is 256 bytes ?

A block in the native format has 1024 bytes.

> Will this

What's "this"?

> help since minimum period time of snd_ymfpci is 5.333ms but
> alsa-pulse plugin announce a lower value 128 bytes (period_bytes_min)
> to the alsa application ?

Doesn't PA assume that the hardware has accurate pointer positions?
Without this, smaller periods do not make sense unless PA can
interpolate from the period interrupts.


Regards,
Clemens

Re: Noise using pulseaudio with ymf724f

[Raymond Yau]

2011/9/14 Clemens Ladisch <clemens@ladisch.de>:
> Raymond Yau wrote:
>> Is 256 frames/period in s16 stereo since the card support mono ,
>> stereo , U8 and S16 ,
>
> The hardware uses S16 stereo at 48 kHz internally; everything else is
> converted and resampled to that.

using ubuntu 11.04 Live CD

After select "Mono Duplex" profile in gnome sound preference  , gnome
speaker-test crash

>
>> What is the meaning of SNDRV_PCM_INFO_BLOCK_TRANSFER
>
> That the card transfers samples in blocks.
>
>> since the rewind_safeguard of PA server is 256 bytes ?
>
> A block in the native format has 1024 bytes.
>

Do you mean hardware pointer is only updated every 5.333ms ?

similar to usb audio using 5 urbs

and this is why the driver force the application to use 3 periods per buffer

>> help since minimum period time of snd_ymfpci is 5.333ms but
>> alsa-pulse plugin announce a lower value 128 bytes (period_bytes_min)
>> to the alsa application ?
>
> Doesn't PA assume that the hardware has accurate pointer positions?
> Without this, smaller periods do not make sense unless PA can
> interpolate from the period interrupts.
>

PA server use the value from snd_pcm_available() to determine the sleep time ,
You have to ask PA developer whether PA can interpolate from the
period interrupts

e.g. hda , emu10k1 and au88x0 use the values from hardware register as
the playback position in pointer callback

Re: Noise using pulseaudio with ymf724f

[Clemens Ladisch]

Raymond Yau wrote:
> 2011/9/14 Clemens Ladisch <clemens@ladisch.de>:
> > A block in the native format has 1024 bytes.
> 
> Do you mean hardware pointer is only updated every 5.333ms ?

Yes.


Regards,
Clemens

Re: Noise using pulseaudio with ymf724f

[Raymond Yau]

2011/9/16 Clemens Ladisch <clemens@ladisch.de>:
> Raymond Yau wrote:
>> 2011/9/14 Clemens Ladisch <clemens@ladisch.de>:
>> > A block in the native format has 1024 bytes.
>>
>> Do you mean hardware pointer is only updated every 5.333ms ?
>
> Yes.
>
>

The noise can also be reproduced by change the value of the hw ptr of
hda-intel with 0xffffff00 so that it provide an less accurate pointer
position



diff --git a/sound/pci/hda/hda_intel.c b/sound/pci/hda/hda_intel.c
index 2a8bed9..0ef368d 100644
--- a/sound/pci/hda/hda_intel.c
+++ b/sound/pci/hda/hda_intel.c
@@ -1574,8 +1574,8 @@ static struct snd_pcm_hardware azx_pcm_hw = {
 				 /* No full-resume yet implemented */
 				 /* SNDRV_PCM_INFO_RESUME |*/
 				 SNDRV_PCM_INFO_PAUSE |
-				 SNDRV_PCM_INFO_SYNC_START |
-				 SNDRV_PCM_INFO_NO_PERIOD_WAKEUP),
+				 SNDRV_PCM_INFO_SYNC_START /* |
+				 SNDRV_PCM_INFO_NO_PERIOD_WAKEUP */),
 	.formats =		SNDRV_PCM_FMTBIT_S16_LE,
 	.rates =		SNDRV_PCM_RATE_48000,
 	.rate_min =		48000,
@@ -1639,6 +1639,8 @@ static int azx_pcm_open(struct snd_pcm_substream
*substream)
 				   buff_step);
 	snd_pcm_hw_constraint_step(runtime, 0, SNDRV_PCM_HW_PARAM_PERIOD_BYTES,
 				   buff_step);
+	snd_pcm_hw_constraint_minmax(runtime,
SNDRV_PCM_HW_PARAM_PERIOD_TIME, 5333, UINT_MAX);
+	snd_pcm_hw_constraint_minmax(runtime, SNDRV_PCM_HW_PARAM_PERIODS, 3, 1024);
 	snd_hda_power_up(apcm->codec);
 	err = hinfo->ops.open(hinfo, apcm->codec, substream);
 	if (err < 0) {
@@ -1986,7 +1988,7 @@ static snd_pcm_uframes_t azx_pcm_pointer(struct
snd_pcm_substream *substream)
 	struct azx *chip = apcm->chip;
 	struct azx_dev *azx_dev = get_azx_dev(substream);
 	return bytes_to_frames(substream->runtime,
-			       azx_get_position(chip, azx_dev));
+			       azx_get_position(chip, azx_dev)) & 0xffffff00;
 }

 /*
-- 
1.6.0.6