Stumped with multi-channel USB sound output

[Hans Petter Selasky]

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: <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

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: <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?

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