On 04/03/2014 11:16 AM, Daniel Mack wrote:

>> TEAC TEAC USB AUDIO DEVICE at usb-0000:00:1d.0-1.4, high speed : USB Audio
>
> That's a device with IDs 0644:8038, correct?

That's right, here's how the USB stack announces it:

[67129.718571] hid-generic 0003:0644:8038.0006: input,hidraw2: USB HID 
v1.00 Device [TEAC TEAC USB AUDIO DEVICE] on usb-0000:00:1d.0-1.4/input0

> Interface 3 refers to ...
>
>>       Altset = 2
>>       Packet Size = 156
>>       Momentary freq = 183992 Hz (0x16.ffc0)
>>       Feedback Format = 16.16
>>     Interface 3
>>       Altset 1
>>       Format: S16_LE
>
> ... 16bit, so things don't work for you in 192k/16bit, right?

Well, it's not like I had experienced a lot with it, but the few times I 
tried 16/192, I didn't hear the crackles that are very noticeable in 
24/192. More on this below

> Just for the sake of comparison, could you try playing the following
> file with aplay?
>
>    http://zonque.org/sine-192khz.wav (~22 MB)
>
> I get stable sound output with
>
>    aplay -Dhw:xxx --buffer-size=256 Music/sine-192khz.wav

I just tried to playback this file with your buffer size and I can 
confirm there are issues in 16/192 too: with buffer-size=256, lots of 
crackle s. Buffer needs to be raised to 384/512 to sound normal.

Yesterday I got my hands on more diverse 24/192 content to make more 
experiments. I've come to the conclusion that the crackles that were 
very noticeable with the patch mentioned upper in the thread are not 
100% absent without the patch, they are just very less frequent and 
harder to notice, but are still there. The experiments I made yesterday 
were using aplay, without specifying any buffer size, here's what aplay 
-vD[..] gives playing some of this new content without specifying the 
buffer size:

Its setup is:
   stream       : PLAYBACK
   access       : RW_INTERLEAVED
   format       : S24_3LE
   subformat    : STD
   channels     : 2
   rate         : 192000
   exact rate   : 192000 (192000/1)
   msbits       : 24
   buffer_size  : 96000
   period_size  : 24000
   period_time  : 125000
   tstamp_mode  : NONE
   period_step  : 1
   avail_min    : 24000
   period_event : 0
   start_threshold  : 96000
   stop_threshold   : 96000
   silence_threshold: 0
   silence_size : 0
   boundary     : 6755399441055744000
   appl_ptr     : 0
   hw_ptr       : 0

Seems to default to a much bigger buffer size. What's interesting that 
if a smaller buffer (e.g: 512) is specified I'm really unable to spot 
any crackle. Could it be a question of sweet spot that some apps have a 
hard time finding?

--
Julien Benoist

------------------------------------------------------------------------------
_______________________________________________
Alsa-user mailing list
Alsa-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/alsa-user

Reply via email to