Lennart Poettering wrote: > Particularly with USB I experience that right after the device is > started data is read much much faster from the playback buffer than > expected. This feels as if the USB driver would at the beginning take > all data from the playback buffer and copy it to some other buffer > which was previously completely empty. Then after that second buffer > is filled up the copying slows down to the expected speed. Yes, the USB driver uses double-buffering, and the initial queueing of data for the USB controller is done at faster rate, to reduce the startup latency. The size of the second buffer is about one period, but never more than 64 ms. > I currently deal with this by always halving the first wakeup time -- > which works most of the time but is a hack. In theory, you could deduce this behaviour from snd_pcm_hw_params_is_double(), but the USB driver forgets to set this flag. > With the function I suggest I'd be able to explicitly query how much > time I have before I need to wake up. I was thinking about a function that returns the hardware's block size (i.e., the precision of the avail/delay values), but that wouldn't be able to describe this behaviour of the USB driver. I think I might just remove this feature. > > Well, you could make the "some extra margin" above larger than one > > period. > > To save power I want to disable interrupts from the sound cards as > much as possible. In some cases (unusal hardware, but also USB), the period size affects the block size, i.e., smaller periods give better timing precision. For this case, it might be useful to make the "pointer precision" a hardware parameter that can be restricted by an interval, like the other parameters. Best regards, Clemens _______________________________________________ Alsa-devel mailing list Alsa-devel@xxxxxxxxxxxxxxxx http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
