[alsa-devel] Period time/size in adaptive USB - alignment to nrpacks?
pavel.hofman at ivitera.com
Wed Dec 28 21:04:15 CET 2011
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
> 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 at 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
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_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
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
>> 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,
More information about the Alsa-devel