It’s easy to SSH to BDP-2 and change Roon endpoint config file to use ALSA tee plugin for capturing output to wav file
This is your problem. RAAT does not play nicely with software-based ALSA “devices” that don’t exhibit clocking behavor sufficiently close to that of a real “sound card”. This relates to the technical details of how we recover the clock from the device and expose it back to Roon.
We do not generally certify Roon Ready devices that use ALSA devices other than hw:X,X because we are unable to warrant the accuracy of Signal Path without direct access to the hardware, and because of problems like the one you are running into. We also do not certify Roon Ready devices without confirming that they are capable of bit-perfect playback.
In order to run a meaningful test, you must collect the samples via the USB or S/PDIF/AES ports without tampering with the software.
Can Roon confirm that there is no guaranteed delivery of all PCM frames to network endpoint?
We would have to be complete and utter fools to design an streaming protocol for music playback that dropped audio each time a single UDP packet was lost.
RAAT has a reliability mechanism that detects dropped UDP packets and re-transmits them. There is a substantial buffer in the endpoint, which allows us to potentially retry many times before it becomes “too late”. RAAT is a reliable protocol, just like TCP.
Any networked audio playback system–regardless of whether it is based on TCP, or UDP, has to make a decision about what to do if the data does not “get there” in time. In RAAT’s case, this means that an audio packet was dropped, and then 20 or more re-transmit attempts for that packet failed (in other words, the network is totally broken).
Were that to happen, RAAT would replace the missing audio with 0-samples (PCM) or 0x69 samples (DSD).
A whole packet of missing audio would produce an audible click/pop that would be jarring to a layman who’s not paying close attention, and it would reflect as a string of hundreds of 0-samples on a capture like the one you posted.
Can buying managed switch improve the situation? Will it give 100% delivery of UDP packets?
Packet loss is very rare on wired home ethernet networks. Rare enough that in order to test RAAT’s robustness on poor networks, we must use simulation tools to test these situations.
Could a higher quality switch with larger internal buffers theoretically reduce packet loss in extreme situations? Sure, but that has nothing to do with whether it is managed or not. Since packet loss isn’t the problem here, I don’t think this is the road to go down.
- Why Roon does not have any indicator of stream quality? Perhaps you may use TCP for passing checksums.
UDP has a checksum mechanism built in to prevent the delivery of corrupt packets (corrupt packets are dropped before they reach our code), so additional checksums on our end are not needed–detecting drops is sufficient.
We do use TCP to report dropouts back to Roon when they occur. Dropouts are tracked and logged. If a concerning quantity is detected, Roon ends playback, displays a message to the user, and moves onto the next track.