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

[Pavel Hofman <pavel.hofman@ivitera.com>]

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