Hi Louis,
On Oct 4 2016 00:08, Pierre-Louis Bossart wrote:
On 10/3/16 1:46 AM, Takashi Sakamoto wrote:
Hi,
On Sep 30 2016 21:43, Subhransu S. Prusty wrote:
From: Pierre-Louis Bossart pierre-louis.bossart@linux.intel.com
For playback usages, the endpoints are started before the prepare step,
As long as I understand, in ALSA USB audio device class driver, submitting URBs starts at .prepare called by PCM core. So not before it as long as the 'prepare step' means .prepare call.
The comment should have said 'started during the prepare step', you're right.
OK. Thanks for your confirmation.
We have the similar design in drivers with IEC 61883-1/6 packet streaming engine for Audio and Music units on IEEE 1394 bus (locates in sound/firewire/*). This is the reason I have interests in this patchset.
and valid audio data will be rendered with a delay that cannot be recovered. Worst-case the initial delay due to buffering of empty URBS can be up to 12ms
I thinks the aim of this patch is to add proper delay to current calculation of estimated delay, due to the URBs accumulated between .prepare and .trigger call. If so, it's better to explain about it in the comment so that the other developers such as me can follow this improvement.
Yes indeed. will fix but as replied to Takashi Iwai there are wider questions on why endpoints can't be linked and why the start times can't be set by the class driver.
From me, an additional question.
There's no guarantee that applications call ioctl() with SNDRV_PCM_IOCTL_START within 12 msec after ioctl() with SNDRV_PCM_IOCTL_PREPARE. In this case, more URBs might be sumitted by usb_submit_urb/snd_complete_urb() cycle, as long as I understand. So it's quite rough to compute based on MAX_URBS (=12).
I think it better to use actual time (monotonic time or something suitable) to compute the additional delay between .prepare and .trigger calls. Or calculate queued packet between the two calls, then compute the delay.
Thanks
Takashi Sakamoto