[alsa-devel] Period time/size in adaptive USB - alignment to nrpacks?
Hi,
I have been analyzing USB URBs in wireshark. Output stream, adaptive mode, 16 bits, 48kHz, stereo. Each URB is issued always at nrpacks milliseconds. Each URB transfers 48 samples * 2 bytes * 2 channels * nrpacks milliseconds of bytes. The last URB of period keeps the same pace (nrpacks milliseconds), however holds only the remaining number of bytes. This creates ripples in the data stream bitrate, possibly leading to increased jitter of the PLL'd clock in the USB receiver.
When period size is aligned to multiples of samplerate/1000 * audio frame bytes * nrpacks, all URBs carry constant number of bytes.
I am wondering if for the xx.000 Hz samplerates it made sense to offer only these aligned multiples in snd_pcm_hw_params_set_period_time_near.
Thank you for your expert opinion.
Best regards,
Pavel.
Pavel Hofman wrote:
Each URB is issued always at nrpacks milliseconds. Each URB transfers 48 samples * 2 bytes * 2 channels * nrpacks milliseconds of bytes. The last URB of period keeps the same pace (nrpacks milliseconds), however holds only the remaining number of bytes.
No, the period's last URB uses only as many frames as needed.
This creates ripples in the data stream bitrate, possibly leading to increased jitter of the PLL'd clock in the USB receiver.
Did you actually observe this?
I am wondering if for the xx.000 Hz samplerates it made sense to offer only these aligned multiples in snd_pcm_hw_params_set_period_time_near.
Only for adaptive playback. And the URB length is also derived from the period size, so I'd be interested in seeing how this constraint would be implemented.
Regards, Clemens
Dne 28.12.2011 14:00, Clemens Ladisch napsal(a):
Each URB is issued always at nrpacks milliseconds. Each URB transfers 48 samples * 2 bytes * 2 channels * nrpacks milliseconds of bytes. The last URB of period keeps the same pace (nrpacks milliseconds), however holds only the remaining number of bytes.
No, the period's last URB uses only as many frames as needed.
Clemens, thanks for your reply. I rechecked and you are right, there is a faster URB, but here is what I am actually getting in wireshark:
nrpacks = default 8
pavel@nahore:~$ aplay -v -D plughw:1 audio/48-long.wav Přehrávám WAVE 'audio/48-long.wav' : Signed 16 bit Little Endian, Frekvence 48000 Hz, Stereo Plug PCM: Hardware PCM card 1 'C-Media USB Headphone Set' device 0 subdevice 0 Its setup is: stream : PLAYBACK access : RW_INTERLEAVED format : S16_LE subformat : STD channels : 2 rate : 48000 exact rate : 48000 (48000/1) msbits : 16 buffer_size : 24000 period_size : 6000 period_time : 125000 period_time : 125000 tstamp_mode : NONE period_step : 1 avail_min : 6000 period_event : 0 start_threshold : 24000 stop_threshold : 24000 silence_threshold: 0 silence_size : 0 boundary : 1572864000 appl_ptr : 0 hw_ptr : 0
This period (6000 x 2 x 2 = 24000 bytes) produces 15 URBs with 1536 bytes followed by 1 URB with 960 bytes.
Now please see the wireshark screenshot at http://personal.educity.cz/dustin/wireshark.png . Frame 1197 is the last URB of the period, with 960 bytes only. Yet the time distance around it is again 8 ms (12.808-12.816-12.824). The expected 5 ms lag appears 2 URBs later, between frames 1201 and 1203 (12.832-12.837), all holding 1536 bytes.
It may be just a bug in wireshark or libpcap. Please is there another way to cross-check?
This creates ripples in the data stream bitrate, possibly leading to increased jitter of the PLL'd clock in the USB receiver.
Did you actually observe this?
No, it was just my conclusion. I am afraid I do not have any proper equipment to check.
I am wondering if for the xx.000 Hz samplerates it made sense to offer only these aligned multiples in snd_pcm_hw_params_set_period_time_near.
Only for adaptive playback. And the URB length is also derived from the period size, so I'd be interested in seeing how this constraint would be implemented.
Actually it would be useless if everything is OK and the bitrate is being kept steady :-)
Thanks a lot for your expert advice,
Pavel.
Pavel Hofman wrote:
Now please see the wireshark screenshot at http://personal.educity.cz/dustin/wireshark.png . Frame 1197 is the last URB of the period, with 960 bytes only. Yet the time distance around it is again 8 ms (12.808-12.816-12.824). The expected 5 ms lag appears 2 URBs later, between frames 1201 and 1203 (12.832-12.837), all holding 1536 bytes.
Wireshark shows the URBs when they are submitted, which is in the completion handler of some previous URB. This means that the timing of the submission has no relation with its size.
Regards, Clemens
On 29.12.2011 09:43, Clemens Ladisch wrote:
Pavel Hofman wrote:
Now please see the wireshark screenshot at http://personal.educity.cz/dustin/wireshark.png . Frame 1197 is the last URB of the period, with 960 bytes only. Yet the time distance around it is again 8 ms (12.808-12.816-12.824). The expected 5 ms lag appears 2 URBs later, between frames 1201 and 1203 (12.832-12.837), all holding 1536 bytes.
Wireshark shows the URBs when they are submitted, which is in the completion handler of some previous URB. This means that the timing of the submission has no relation with its size.
Hi Clemens, thanks a lot for the clarification. Everything seems to be all right and verified :-)
Best regards,
Pavel.
participants (2)
-
Clemens Ladisch -
Pavel Hofman