Stumped with multi-channel USB sound output

[Andrew Reilly]

Hi HPS,

Thanks for the quick reply.  I'm afraid that I'm not keeping up my end of the deal...

I sampled the feedback_rate at two second intervals for a little while and the result looks like this:

dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 47999
dev.pcm.0.feedback_rate: 48000
dev.pcm.0.feedback_rate: 47999

I'm a bit confused about what purpose this value serves.  With only a single DAC in the system (no ADC, no asynchronous clocks), why not accept it's clock as authoritative?  Is the driver/feeder actually running from the processor clock or a system timer?

Regarding USB connection topology, the DAC is plugged directly into a USB-3 socket on the back of the motherboard, using the cable that came with it.  According to the dmesg, that socket is hooked up via a hub on the motherboard, apparently.  That's not unusual, is it?

xhci1: <AMD KERNCZ USB 3.0 controller> mem 0xfe100000-0xfe1fffff irq 37 at device 0.3 on pci11
xhci1: 64 bytes context size, 64-bit DMA
usbus1 on xhci1
usbus1: 5.0Gbps Super Speed USB v3.0
:
uhub0: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus1
uhub1: <0x1022 XHCI root HUB, class 9/0, rev 3.00/1.00, addr 1> on usbus0
:
uhub0: 8 ports with 8 removable, self powered
uhub1: 22 ports with 22 removable, self powered
ugen1.2: <miniDSP U-DAC8> at usbus1
uaudio0 on uhub0
uaudio0: <U-DAC8> on usbus1

That USB bus does seem to be shared with my external (backup) hard drive enclosure:
ugen1.3: <ICY BOX ICY BOX IB-3620> at usbus1
umass0 on uhub0
umass0: <ICY BOX ICY BOX IB-3620, class 0/0, rev 3.00/1.00, addr 2> on usbus1
umass0:  SCSI over Bulk-Only; quirks = 0xc100
umass0:5:0: Attached to scbus5
da0 at umass-sim0 bus 0 scbus5 target 0 lun 0
da0: <ICY BOX ICY BOX IB-3620 83XN> Fixed Direct Access SCSI device

No doubt that will not be ideal, but that drive is off-line most of the time, so I would hope that there's not much activity there.

Turning on sysctl.usb.uaudio.debug=15 mostly has a stream of "transferring 12288 bytes", but occasionally says:

uaudio_chan_play_callback: transferring 12288 bytes
uaudio_chan_play_callback: transferring 12288 bytes
uaudio_chan_play_sync_callback: transferred 4 bytes
uaudio_chan_play_sync_callback: Value = 0x0005fff8
uaudio_chan_play_sync_callback: Comparing 47999 Hz :: 48000 Hz
uaudio_chan_play_callback: sending one sample less
uaudio_chan_play_callback: transferring 12256 bytes
uaudio_chan_play_callback: transferring 12288 bytes
uaudio_chan_play_callback: transferring 12288 bytes
uaudio_chan_play_callback: transferring 12288 bytes

I can see that occasional clock differences (vs what reference?) like this can be accommodated by allowing ring buffers to drift or get imperfectly aligned, but that is not what I'm hearing, I think.  12288 bytes is 8*4*384, so 384 samples, or 8ms, right?  That does tally with the buffer size reported in dmesg.

Is that "transferred 4 bytes", "Value = 0x0005fff8" saying that the feedback frequency is coming from the device (DAC) itself?

Regarding hacking on uaudio_chan_play_sync_callback, the calculations for the feedback rate seem correct, and I would say that they seem to be producing a "correct" value, I just don't understand its significance, yet.

Thanks again for your help!

Cheers,

Andrew Reilly
M: 0409-824-272
areilly at bigpond.net.au



> On 26 Dec 2018, at 19:36 , Hans Petter Selasky <hps at selasky.org> wrote:
> 
> On 12/26/18 5:44 AM, Andrew Reilly wrote:
>> Hi there,
>> I've recently acquired one of these:
>> https://www.minidsp.com/products/usb-audio-interface/u-dac8 to do some multi-amp speaker crossover hi-fi tweaking.  Since my FreeBSD-12.STABLE file server is quite close to my amplifier, I thought that I'd start by using it to drive the DAC.
>> It is a USB Audio Class 2.0 device, and as such is recognised seemingly well by the snd_uaudio driver (loaded by /boot/loader.conf, as it doesn't seem to be compiled-in):
> 
> Hi,
> 
>> and for dev.pcm:
>> dev.pcm.0.feedback_rate: 47999
> 
> ^ can you sample this parameter over time. Because your device does not have any recording endpoints, this value will be used to decide how many additional or less samples will be sent. Also check the that USB cable has good connection. Sometimes if the cable is slightly bad, data may be lost. Isochronous traffic has no re-transmi.
> 
> Try also to enable USB audio debugging:
> 
> sysctl hw.usb.uaudio.debug=15
> 
>> dev.pcm.0.mixer.mute_1.desc:
>> dev.pcm.0.mixer.mute_1.max: 1
>> dev.pcm.0.mixer.mute_1.min: 0
>> dev.pcm.0.mixer.mute_1.val: 0
>> dev.pcm.0.mixer.vol_0.desc:
>> dev.pcm.0.mixer.vol_0.max: 0
>> dev.pcm.0.mixer.vol_0.min: -32512
>> dev.pcm.0.mixer.vol_0.val: -11475
>> dev.pcm.0.bitperfect: 0
>> dev.pcm.0.buffersize: 0
>> dev.pcm.0.play.vchanformat: s16le:2.0
> 
> ^
> In order to use 8 channels you need to set this sysctl to s32le:7.1 or s24le:7.1
> 
>> dev.pcm.0.play.vchanrate: 48000
>> dev.pcm.0.play.vchanmode: fixed
>> dev.pcm.0.play.vchans: 1
>> dev.pcm.0.hwvol_mixer: vol
>> dev.pcm.0.hwvol_step: 5
>> dev.pcm.0.%parent: uaudio0
>> dev.pcm.0.%pnpinfo:
>> dev.pcm.0.%location:
>> dev.pcm.0.%driver: pcm
>> dev.pcm.0.%desc: USB audio
>> dev.pcm.%parent:
> 
> 
>> I think that is saying (working from the bottom up) that userland is sending data which is being sample-rate converted using the default (q:1) sample rate converter to 48kHz, and then feeder_matrix(2.0 -> 7.1) is probably trying to do the right thing to drive eight output channels?
> 
> Unless you set the bitperfect option or vchanformat, this is the case.
> 
>> That looks as though my eight channels is being mixed down to two (on the last line) and then up-mixed to eight (7.1)?  I don't want it to do that.  How do I stop it?
> 
> See hints about setting sysctl options.
> 
>> Also, this hardware is perfectly capable of running at 44100Hz, as shown in the dmesg output.  Is there a way to tell the pcm driver to set the hardware sample rate, rather than do sample rate conversion in software?
> 
> sysctl hw.usb.uaudio.default_rate=44100
> 
>> Is there any documentation about any of this?  The pcm(4) man page says that there is matrixing support to handle channel routing and up/down mixing, but it isn't particularly clear about the possibilities.
> 
>> but the audio output distortion is the same.  Despite the distorted output, sndstat is indicating that there are no underruns, and there are no kernel messages showing up in the dmesg buffer about pcm misbehaviour.
> 
> The problem is the formula in:
> 
> static void
> uaudio_chan_play_sync_callback(struct usb_xfer *xfer, usb_error_t error)
> 
> in sys/dev/sound/usb/uaudio.c Maybe you can play with it.
> 
>> Am I going to win, with additional tweaking, do you think?  Or will I be better off setting up a Raspberry Pi or the like, running linux, to drive it?
> 
> Raspberry Pi doesn't work very well with USB audio devices of this kind. What kind of USB host are you using?
> 
> Are there any USB HUBs in between? Try connecting directly to the computer?
> 
>> Where can I find documentation about the mixer/feeder architecture, to interpret those sndstat outputs?
> 
> Maybe send a patch if you think something is very useful?
> 
> --HPS