Period time/size in adaptive USB - alignment to nrpacks?

Period time/size in adaptive USB - alignment to nrpacks?

[Pavel Hofman]

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.

Re: Period time/size in adaptive USB - alignment to nrpacks?

[Clemens Ladisch]

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

Re: Period time/size in adaptive USB - alignment to nrpacks?

[Pavel Hofman]

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

Re: Period time/size in adaptive USB - alignment to nrpacks?

[Clemens Ladisch]

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

Re: Period time/size in adaptive USB - alignment to nrpacks?

[Pavel Hofman]

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.