At 2012-07-17T10:59:23+0530, Arun Raghavan wrote: > The necessary values are available via pa_stream_get_buffer_attr(). > Potentially we could use this in the pulse_pointer() function to update > the corresponding snd_pcm_t's period/buffer sizes, but I don't know if > this is kosher with regards to what alsa-lib expects plugins to be > doing.
Right, I assume alsa-lib expects the buffer size to be static after configuration is complete, and from a quick search through the source of alsa-lib and alsa-plugins I couldn't find any code that updated the buffer size after configuration. > If this is not sufficient for the initial update, from what I can see, > snd_pcm_set_params() first sets period/buffer sizes, queries them for > later calculations, and then commits them with snd_pcm_hw_params(). If > we could move the querying to after the params are committed (and in > this case, the stream is connected and buffer attributes are > negotiated), that would solve your problem. Again, I'm not sure what > side-effects this might have, but I've attached a draft untested patch > for it. Unless I'm missing something, the queried buffer_size in that function is only used to set the start_threshold later on, and doesn't update pcm->buffer_size. At 2012-07-17T08:22:20+0200, David Henningsson wrote: > 100 ms of latency is a lot, even for PulseAudio - is this some > special hardware? No, it's just a random value for media playback. In an older version of the audio backend we're using in Firefox (which was push rather than pull based), we used 500ms and hadn't run into this problem in a way that was obvious to users (i.e. causing broken playback). I chose a lower latency for media playback in the new backend in an attempt to flush out bugs before we introduce features that demand low latency (such as WebRTC). > Could you clarify what versions of PulseAudio and alsa-plugins > you're using? The latest improvement to this handling was done less > than a year ago and might require the latest versions of these > components. I'm using Fedora 17, which has alsa-plugins-pulseaudio-1.0.25-3.fc17 and pulseaudio-1.1-9.fc17. This was originally discovered by users running ALSA 1.0.25 on various distros (Ubuntu 12.04 LTS and Arch). Two of them happened to have a PA server where the latency had crept up over time, and a third was running the server with tsched=0 on an Audigy SE (CA0106) with a minimum latency of 200ms. I've also tested against the git HEAD of alsa-plugins. > I think the better solution would be nr 2 in this case. Nr 1 won't > solve the case where the sink's latency is increased dynamically - > because the stream is moved, for example. > I don't know either - and it also does not seem to solve the case > where the sink's latency is suddenly increased (e g, when the sink > input is moved to another sink). At 2012-07-17T15:36:52+0800, Raymond Yau wrote: > this function does not work for all sound card drivers. > > many pci sound cards have hardware constraints which you cannot select 10ms > or 100ms period time / buffer time. That's fine, as long as it fails by either silently using the appropriate buffer/period sizes and reporting them via the ALSA API, or causes snd_pcm_set_params to return an error so another configuration can be attempted. The problem in this situation is that neither of those things happen under the conditions I described. > do you mean the pulse plugin advertise a low latency but the server in fact > force the application to use a large buffer with high latency? Yes. The code in pcm_pulse.c:pulse_hw_constraint reports fixed min/max sizes for buffers and periods without verifying that the PA server can honour those values. When it can't, PA will increase PA stream buffer size (tlength) as appropriate, but this isn't reflected in the plugin or ioplug/pcm layers of ALSA, so the calling application can't detect this and adjust accordingly. Cheers, -mjg _______________________________________________ pulseaudio-discuss mailing list pulseaudio-discuss@lists.freedesktop.org http://lists.freedesktop.org/mailman/listinfo/pulseaudio-discuss
