From owner-freebsd-multimedia@freebsd.org Sun Dec 30 11:58:00 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 8C8D5142469A for ; Sun, 30 Dec 2018 11:58:00 +0000 (UTC) (envelope-from hps@selasky.org) 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 0774D82A7A for ; Sun, 30 Dec 2018 11:58:00 +0000 (UTC) (envelope-from hps@selasky.org) Received: by mailman.ysv.freebsd.org (Postfix) id BF2321424693; Sun, 30 Dec 2018 11:57:59 +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 9CBFE1424690 for ; Sun, 30 Dec 2018 11:57:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from mail.turbocat.net (turbocat.net [IPv6:2a01:4f8:c17:6c4b::2]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 2DAED82A79 for ; Sun, 30 Dec 2018 11:57:59 +0000 (UTC) (envelope-from hps@selasky.org) Received: from hps2016.home.selasky.org (unknown [178.17.145.230]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by mail.turbocat.net (Postfix) with ESMTPSA id 12EF12600CB; Sun, 30 Dec 2018 12:57:56 +0100 (CET) Subject: Re: Stumped with multi-channel USB sound output To: Andrew Reilly Cc: multimedia@freebsd.org References: <5042D970-166F-4D13-8B0C-BD7216064567@bigpond.net.au> <2e491e79-cc0b-9742-c907-fdb89b130f40@selasky.org> <9D48BA50-A168-45FA-BE7A-D1A65A2B9A68@bigpond.net.au> From: Hans Petter Selasky Message-ID: <83050e37-25d2-f371-e955-9850264ad4f0@selasky.org> Date: Sun, 30 Dec 2018 12:55:36 +0100 User-Agent: Mozilla/5.0 (X11; FreeBSD amd64; rv:60.0) Gecko/20100101 Thunderbird/60.4.0 MIME-Version: 1.0 In-Reply-To: <9D48BA50-A168-45FA-BE7A-D1A65A2B9A68@bigpond.net.au> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Rspamd-Queue-Id: 2DAED82A79 X-Spamd-Bar: ------ Authentication-Results: mx1.freebsd.org X-Spamd-Result: default: False [-6.99 / 15.00]; NEURAL_HAM_MEDIUM(-1.00)[-1.000,0]; NEURAL_HAM_SHORT(-0.99)[-0.988,0]; REPLY(-4.00)[]; NEURAL_HAM_LONG(-1.00)[-1.000,0] 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: Sun, 30 Dec 2018 11:58:00 -0000 On 12/30/18 12:15 AM, Andrew Reilly wrote: > 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 Hi Andrew, These values look normal. > 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? Your device reports it is using its own clock, so the sample stream needs to be corrected every now and then. > > 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 What does "usbconfig" output, when run as root? Can you try another socket on the motherboard? > > 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 = 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=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? Yes. > > 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. --HPS