Date: Sun, 30 Dec 2018 10:15:29 +1100 From: Andrew Reilly <areilly@bigpond.net.au> To: Hans Petter Selasky <hps@selasky.org> Cc: multimedia@freebsd.org Subject: Re: Stumped with multi-channel USB sound output Message-ID: <9D48BA50-A168-45FA-BE7A-D1A65A2B9A68@bigpond.net.au> In-Reply-To: <2e491e79-cc0b-9742-c907-fdb89b130f40@selasky.org> References: <5042D970-166F-4D13-8B0C-BD7216064567@bigpond.net.au> <2e491e79-cc0b-9742-c907-fdb89b130f40@selasky.org>
next in thread | previous in thread | raw e-mail | index | archive | help
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 =3D 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=3D15 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 =3D 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 =3D 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@bigpond.net.au > On 26 Dec 2018, at 19:36 , Hans Petter Selasky <hps@selasky.org> = wrote: >=20 > 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): >=20 > Hi, >=20 >> and for dev.pcm: >> dev.pcm.0.feedback_rate: 47999 >=20 > ^ 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. >=20 > Try also to enable USB audio debugging: >=20 > sysctl hw.usb.uaudio.debug=3D15 >=20 >> 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 >=20 > ^ > In order to use 8 channels you need to set this sysctl to s32le:7.1 or = s24le:7.1 >=20 >> 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: >=20 >=20 >> 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? >=20 > Unless you set the bitperfect option or vchanformat, this is the case. >=20 >> 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? >=20 > See hints about setting sysctl options. >=20 >> 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? >=20 > sysctl hw.usb.uaudio.default_rate=3D44100 >=20 >> 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. >=20 >> 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. >=20 > The problem is the formula in: >=20 > static void > uaudio_chan_play_sync_callback(struct usb_xfer *xfer, usb_error_t = error) >=20 > in sys/dev/sound/usb/uaudio.c Maybe you can play with it. >=20 >> 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? >=20 > Raspberry Pi doesn't work very well with USB audio devices of this = kind. What kind of USB host are you using? >=20 > Are there any USB HUBs in between? Try connecting directly to the = computer? >=20 >> Where can I find documentation about the mixer/feeder architecture, = to interpret those sndstat outputs? >=20 > Maybe send a patch if you think something is very useful? >=20 > --HPS
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?9D48BA50-A168-45FA-BE7A-D1A65A2B9A68>