Search results

There is no issue logged. IMO the distortions are produced by upstream - by the player.

Yes, nice log. IMO there are no issues there. Did some sound issue occur during the period of the log? If so, then it may be upstream from CDSP.

OK, now please post debug log which shows how the playback buffer level develops during playback, along with setrate adjustments You have target level at 3 chunks which looks OK, but I would like to see the actual buffer size and buffer level, to config the rate adjust really works in your...

@ClintEastw00d: There is no way to troubleshoot remotely without any info. Your CDSP config file is the first step. Based on your description I would guess some issues around rate adjust.

That's what I am saying - if Waxwing sets the spdif preamble incorrectly, wiim would detect 16 bits format. But it may still be receiving (and using) all 24 bits since SPDIF always has 24 bit positions in the stream (with the lower bits set to zero by the transmitter, if it really transmits...

The Waxwing user guide says the output format is just 24/48(96): SPDIF always uses 24 bits for the audio sample. It's up to the transmitter to set bits in the SPDIF preamble to specify how many of those 24 bits are actually effective: IMO the Waxwing just sets the the SPDIF preamble...

8k/60Hz passthrough with audio splitter - that looks like some heavy lifting....

That's interesting, does it mean Dante renderers are not aware of the RTP samplerate? Copilot says that the samplerate is communicated to the renderers via SDP in AES67 and Ravenna, as well as in the Dante proprietary control protocol.

Differential Line Driver https://www.ti.com/lit/ds/symlink/ds8921.pdf ?

UAC1/2 support of that embOS is actually quite comprehensive, including explicit async feedback https://www.segger.com/doc/UM09001_emUSBD.html#Audio . Of course no device quirks. Nice, thanks for the link. Of course async resampling would be required (but it can be hardware-based and running...

Incoming SPDIF is clock master. Outgoing USB can be slave (if the USB device is isochronous adaptive - inexpensive headset), or master too (if the USB device is isochronous asynchronous - basically all DACs these days). Two clock masters in one chain must be aligned via asynchronous resampling -...

As for the async feedback - on linux you can check the stream0 file while playing to see what the async feedback looks like. Very useful for troubleshooting any USB-audio device. E.g. https://www.diyaudio.com/community/threads/linux-and-24-96.384600/post-6981562

So standard XMOS interface. Did you test with different linux/computer that the DAC itself produces glitch-free output? E.g. incorrectly implemented async feedback in the xmos firmware would cause regular dropouts.

@Roy_D : unfortunately google does not seem to know any onos dac. Any more info, the dac specs?

What is the output audio device?

What is your measurement ADC?

IMO it's quite unlikely that PA/PW would cause 1 second dropouts. IMO it looks more like issues with delivery of the source stream/file. Nothing in dmesg, no USB issues?

Nothing in dmesg either? Everything goes through your USB, IIUC, both input, output, control...

How do you get your source file? Locally, or over network/wifi?

IIUC OSMC uses kodi/xbmc internally.