* Period time/size in adaptive USB - alignment to nrpacks?
@ 2011-12-26 20:07 Pavel Hofman
2011-12-28 13:00 ` Clemens Ladisch
0 siblings, 1 reply; 5+ messages in thread
From: Pavel Hofman @ 2011-12-26 20:07 UTC (permalink / raw)
To: ALSA development
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Period time/size in adaptive USB - alignment to nrpacks?
2011-12-26 20:07 Period time/size in adaptive USB - alignment to nrpacks? Pavel Hofman
@ 2011-12-28 13:00 ` Clemens Ladisch
2011-12-28 20:04 ` Pavel Hofman
0 siblings, 1 reply; 5+ messages in thread
From: Clemens Ladisch @ 2011-12-28 13:00 UTC (permalink / raw)
To: Pavel Hofman, ALSA development
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Period time/size in adaptive USB - alignment to nrpacks?
2011-12-28 13:00 ` Clemens Ladisch
@ 2011-12-28 20:04 ` Pavel Hofman
2011-12-29 8:43 ` Clemens Ladisch
0 siblings, 1 reply; 5+ messages in thread
From: Pavel Hofman @ 2011-12-28 20:04 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: ALSA development
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.
_______________________________________________
Alsa-devel mailing list
Alsa-devel@alsa-project.org
http://mailman.alsa-project.org/mailman/listinfo/alsa-devel
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Period time/size in adaptive USB - alignment to nrpacks?
2011-12-28 20:04 ` Pavel Hofman
@ 2011-12-29 8:43 ` Clemens Ladisch
2012-01-01 17:01 ` Pavel Hofman
0 siblings, 1 reply; 5+ messages in thread
From: Clemens Ladisch @ 2011-12-29 8:43 UTC (permalink / raw)
To: Pavel Hofman; +Cc: ALSA development
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
^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Period time/size in adaptive USB - alignment to nrpacks?
2011-12-29 8:43 ` Clemens Ladisch
@ 2012-01-01 17:01 ` Pavel Hofman
0 siblings, 0 replies; 5+ messages in thread
From: Pavel Hofman @ 2012-01-01 17:01 UTC (permalink / raw)
To: Clemens Ladisch; +Cc: ALSA development
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.
^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2012-01-01 17:01 UTC | newest]
Thread overview: 5+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2011-12-26 20:07 Period time/size in adaptive USB - alignment to nrpacks? Pavel Hofman
2011-12-28 13:00 ` Clemens Ladisch
2011-12-28 20:04 ` Pavel Hofman
2011-12-29 8:43 ` Clemens Ladisch
2012-01-01 17:01 ` Pavel Hofman
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.
