From owner-freebsd-multimedia@freebsd.org Sat Dec 29 23:55:56 2018 Return-Path: Delivered-To: freebsd-multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 32A501430C58 for ; Sat, 29 Dec 2018 23:55:56 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from mailman.ysv.freebsd.org (mailman.ysv.freebsd.org [IPv6:2001:1900:2254:206a::50:5]) by mx1.freebsd.org (Postfix) with ESMTP id 7AD4D8A9F2 for ; Sat, 29 Dec 2018 23:55:55 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: by mailman.ysv.freebsd.org (Postfix) id 3DA0B1430C57; Sat, 29 Dec 2018 23:55:55 +0000 (UTC) Delivered-To: multimedia@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2610:1c1:1:606c::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id 1B2211430C56 for ; Sat, 29 Dec 2018 23:55:55 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from nsstlmta18p.bpe.bigpond.com (nsstlmta18p.bpe.bigpond.com [203.38.21.18]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "", Issuer "Openwave Messaging Inc." (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 19A478A9F1 for ; Sat, 29 Dec 2018 23:55:45 +0000 (UTC) (envelope-from areilly@bigpond.net.au) Received: from smtp.telstra.com ([10.10.24.4]) by nsstlfep38p-svc.bpe.nexus.telstra.com.au with ESMTP id <20181229231529.GCYS535.nsstlfep38p-svc.bpe.nexus.telstra.com.au@smtp.telstra.com>; Sun, 30 Dec 2018 10:15:29 +1100 X-RG-Spam: Unknown X-RazorGate-Vade-Verdict: clean 0 X-RazorGate-Vade-Classification: clean X-RazorGate-Vade: gggruggvucftvghtrhhoucdtuddrgedtledrtdelgddtlecutefuodetggdotefrodftvfcurfhrohhfihhlvgemucfupfevtfgpvffgnffuvfftteenuceurghilhhouhhtmecufedttdenucenucfjughrpegtggfuhfgjfffgkfhfvffosehtqhhmtdhhtddvnecuhfhrohhmpeetnhgurhgvficutfgvihhllhihuceorghrvghilhhlhiessghighhpohhnugdrnhgvthdrrghuqeenucffohhmrghinhepmhhinhhiughsphdrtghomhenucfkphepuddtuddrudeigedrvdegkedrleegnecurfgrrhgrmhephhgvlhhopegluddtrddtrddtrdduudgnpdhinhgvthepuddtuddrudeigedrvdegkedrleegpdhmrghilhhfrhhomhepoegrrhgvihhllhihsegsihhgphhonhgurdhnvghtrdgruheqpdhrtghpthhtohepoehhphhssehsvghlrghskhihrdhorhhgqedprhgtphhtthhopeeomhhulhhtihhmvgguihgrsehfrhgvvggsshgurdhorhhgqeenucevlhhushhtvghrufhiiigvpedt X-RG-VS-CLASS: clean X-Authentication-Info: Submitted using ID areilly@bigpond.net.au Received: from [10.0.0.11] (101.164.248.94) by smtp.telstra.com (9.0.019.26-1) (authenticated as areilly@bigpond.net.au) id 5C1AEA6002A1F7BC; Sun, 30 Dec 2018 10:15:29 +1100 Content-Type: text/plain; charset=us-ascii Mime-Version: 1.0 (Mac OS X Mail 12.2 \(3445.102.3\)) Subject: Re: Stumped with multi-channel USB sound output From: Andrew Reilly In-Reply-To: <2e491e79-cc0b-9742-c907-fdb89b130f40@selasky.org> Date: Sun, 30 Dec 2018 10:15:29 +1100 Cc: multimedia@freebsd.org Content-Transfer-Encoding: quoted-printable Message-Id: <9D48BA50-A168-45FA-BE7A-D1A65A2B9A68@bigpond.net.au> References: <5042D970-166F-4D13-8B0C-BD7216064567@bigpond.net.au> <2e491e79-cc0b-9742-c907-fdb89b130f40@selasky.org> To: Hans Petter Selasky X-Mailer: Apple Mail (2.3445.102.3) X-Rspamd-Queue-Id: 19A478A9F1 X-Spamd-Bar: -- Authentication-Results: mx1.freebsd.org; dmarc=pass (policy=none) header.from=bigpond.net.au; spf=pass (mx1.freebsd.org: domain of areilly@bigpond.net.au designates 203.38.21.18 as permitted sender) smtp.mailfrom=areilly@bigpond.net.au X-Spamd-Result: default: False [-2.63 / 15.00]; TO_DN_SOME(0.00)[]; R_SPF_ALLOW(-0.20)[+ip4:203.38.21.0/24]; MV_CASE(0.50)[]; FREEMAIL_FROM(0.00)[bigpond.net.au]; RCVD_COUNT_THREE(0.00)[3]; MX_GOOD(-0.01)[extmail.bpbb.bigpond.com,extmail.bpbb.bigpond.com]; RCPT_COUNT_TWO(0.00)[2]; DMARC_POLICY_ALLOW(-0.50)[bigpond.net.au,none]; NEURAL_HAM_SHORT(-0.24)[-0.240,0]; FROM_EQ_ENVFROM(0.00)[]; R_DKIM_NA(0.00)[]; FREEMAIL_ENVFROM(0.00)[bigpond.net.au]; ASN(0.00)[asn:1221, ipnet:203.36.0.0/14, country:AU]; MID_RHS_MATCH_FROM(0.00)[]; RCVD_IN_DNSWL_LOW(-0.10)[18.21.38.203.list.dnswl.org : 127.0.5.1]; ARC_NA(0.00)[]; NEURAL_HAM_MEDIUM(-0.98)[-0.983,0]; FROM_HAS_DN(0.00)[]; NEURAL_HAM_LONG(-0.99)[-0.988,0]; MIME_GOOD(-0.10)[text/plain]; MIME_TRACE(0.00)[0:+]; TO_MATCH_ENVRCPT_SOME(0.00)[]; RCVD_TLS_LAST(0.00)[]; IP_SCORE(-0.01)[country: AU(-0.03)] X-BeenThere: freebsd-multimedia@freebsd.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Multimedia discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Sat, 29 Dec 2018 23:55:56 -0000 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: 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: at usbus1 uaudio0 on uhub0 uaudio0: on usbus1 That USB bus does seem to be shared with my external (backup) hard drive = enclosure: ugen1.3: at usbus1 umass0 on uhub0 umass0: 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: 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 = 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