23.05.2014 08:03, Raymond Yau wrote:
No need to do this. I have already made enough conclusions.
Unfortunately, I forgot to attach the new test program (intentionally
modified to produce an underrun), doing it now.
The output here is:
Hardware PCM card 2 'HDA Intel PCH' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 4 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 4096 period_size : 1024 period_time : 21333 tstamp_mode : NONE period_step : 1 avail_min : 1024 period_event : 0 start_threshold : 1024 stop_threshold : 4096 silence_threshold: 0 silence_size : 0 boundary : 4611686018427387904 appl_ptr : 4096 hw_ptr : 4136 Rewindable: -40, loop iteration: 7807909 This means Too many levels of symbolic links
appl_ptr is 40 samples behind hw_ptr since your program stop writing data to the sound card and perform rewind , snd_pcm_state was change from runnning (3) to xrun (4)
Yes.
The appl_ptr can be placed in any position in the ring buffer for the application to write data but the sound card fetch data from this ring buffer sequentially, however snd_pcm_write() assume the maximum distance between appl_ptr and hwptr is only one buffer
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pc...
Do you mean hwptr does not decrease by one period when you use arbitrary period sizes for hda-Intel ?
I cannot comment on this commit. But "snd_hda_intel.align_buffer_size=1" indeed existed on my kernel command line (for no good reason now - so removed), and I don't use a strange period size.
Still, the bug (negative reported rewindable amount) also exists without align_buffer_size=1.
e.g. 48 samples (192 bytes) when using 1ms period time and stereo instead of 4 channels
Not tested.
you program seen hang when using pulse plugin
I am not interested in any more rewind-related bug reports for the pulse plugin. This particular bug will be fixed, together with many others, by always returning 0 from the .rewindable callback for ioplug if mmap_rw is false.
Sorry, there is no userspace API for that. The only way to get the
minimum period size is via snd_pcm_hw_params_get_period_size_min, which obtains the result in terms of frames.
Have you set channels, rate and format first and you have to call snd_pcm_hw_params_get_period_size_min before you set the period size ?
Yes. The test program is attached. For stereo S16_LE output, it reports 32 samples (i.e. 128 bytes) as the minimum period size. Still, hw_ptr assumes odd values during the test runs. Maybe due to bdl_pos_adj, which is 1 for my analog card. OTOH, with snd_pcm_avail inserted, it assumes even values with a step of 8.
http://git.qemu.org/?p=qemu.git;a=blob;f=hw/audio/ac97.c;hb=HEAD
http://git.qemu.org/?p=qemu.git;a=blob;f=hw/audio/hda-codec.c;hb=HEAD
However those emulated AC97 and HDA sound card inside virtual machine won't transfer audio like the real sound card, it mainly depend on the backend audio driver of the host
These source files are large. What should I look for?
Can your program use period size but pulseaudio server user period time, all rates supported by the sink (at least default rate and alternate rate used by pulseaudio) ?
the supported channels ( at least 2 and 6 which is commonly used)
Sorry, I don't understand. Besides, the program is only intended to demonstrate a bug in snd_pcm_rewindable when applied to the hw plugin, and, before fixing hw, I am not ready to discuss any other bugs that it may find in any other plugin.
How do I test this? Could you please post some userspace test code or
a kernel patch, together with the instructions?
Attach the patch to dump the values of the audio function group capability
There was no attachment.
There are three cases
- delay in analog output > delay in digital output e.g, idt codecs
- delay in analog output < delay in digital output e.g. adi codecs
- no delay in audio widgets , digital output and analog output have no
delay difference when output delay in audio function group is non zero ?
Yes, that's logical.
https://git.kernel.org/cgit/linux/kernel/git/tiwai/sound.git/commit/sound/pc...
Audio send to both Analog and digital output at the same time when iec958 default pcm switch is on
This only affects connections inside the sound card. The same samples will be sent to both outputs (i.e. there will be one stream), thus, any difference in delays will manifest itself.
It is unlikely for ordinary user to measure the delay without using oscilloscope since the Analog speaker and digital receiver also have delay
Correct. Also, while delay in analog speakers can be often rightfully assumed to be 0 samples, this is not the case for digital receivers. In other words, the delay on the digital path is in fact unknown.
However, your considerations above are limited to timing differences between several outputs of the same card. The original use case for module_combine_sink was to combine several analog cards into one, even though they have independent clocks and slightly different (and even changing with temperature) ideas about the meaning of "44100 Hz".
The whole construction should support rewinds, with the
non-rewindable remainder being one JACK period (which may be
different from one ALSA period). If the JACK period is 256 samples, this plugin should behave very much like one voice of ymfpci.
does support snd_pcm_rewind imply support snd_pcm_forward ?
I thought so, but, after thinking a bit more about ADPCM and attempting to fix rewinds there, I am no longer sure. In any case, remembering and reprocessing the past input is a valid way to implement forwards.
(err = snd_pcm_ioplug_set_param_minmax(&jack->io,SND_PCM_IOPLUG_HW_PERIOD_BYTES, 128, 64*1024)) < 0 ||
Like pulse plugin which use same period bytes min as snd-hda-intel
The application can use arbitrary period size but hwptr seem not always change at one period time, this is much worse than those drivers with SNDRV_PCM_INFO_BATCH
For the jack plugin, it is a bug that it hardcodes 128 bytes and thus exposes period sizes less than one jack period. If I have time, I will look into fixing this, too.
what other events pulseaudio need to rewind beside
- change in volume of sink/source
- change in volume of streams
- change in latency
- sync slaves of combined sinks
I don't think that (4) is valid. It is handled by resampling, not rewinding.
5) explicit rewrite request from the client (if the sink has already rendered the rewritten data into its buffer) 6) state change ("If we are added for the first time...") of the sink input 7) corking/uncorking 8) end of underrun (for specific sink inputs) 9) moving streams between sinks
The defaults are: ; default-fragments = 4 ; default-fragment-size-msec = 25
Do you mean if volume change is delayed by one buffer( 0.1 seconds ) is still unacceptable if the user choose 4 x 25ms buffer time for the sink ?
I didn't explicitly mean this. However, please look at this old bug resulting from changing the volume at the wrong time: http://lists.freedesktop.org/archives/pulseaudio-bugs/2010-January/003766.ht... (which is now fixed for all cards that implement deferred volume changes).