Re: [alsa-devel] Noise using pulseaudio with ymf724f
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)
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
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
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
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; }
/*
participants (2)
-
Clemens Ladisch -
Raymond Yau