Given the timeframe, I’m afraid this one might have slipped off the radar somehow.
Let’s flag @support so they can follow-up.
I did receive a PM asking for a second set of logs relatively recently so I think it’s still in the system - just taking a very long time to get any resolution / feedback.
In fairness, if Roon development is still looking into this, they may just not have any news to update you with.
It probably does fall down the pecking order when problems occur that prevent people listening to music at all or with pops and cracks.
I am sure it will eventually show up as one of the myriad of bug fixes that accompany updates.
.sjb.
Fingers crossed.
I’m sorry you feel that this issue is being ignored–that is very far from the truth.
First–I want to be clear about the technical aspects here–zero-padding sample data is an essential part of speaking to device drivers. Most drivers do not natively accept every single format that might appear in a media file. In some schemes (ASIO, for example), the driver is locked to one format always (almost always a 32bit format), and all 16 or 24 bit content is aligned on that boundary. If zero-padding were associated with sound quality problems, then ASIO would not be the preferred driver framework for audiophiles on Windows, and every device would ship with direct support for the full range of formats out there.
This is one detail, among many, of how audio is packed into buffers to be shipped to the device. That’s why it doesn’t show up in signal path–there is some form of buffer packing involved in 100% of audio driver communications. Whether we pack little-endian, big-endian, or with a certain alignment–the exact details of how each device likes their buffer packed are too mundane to draw attention to. It would create more confusion than value if we mis-represented “packing the buffers to send them to the driver” as a processing step, since the audio remains bit-perfect, and since buffer packing is an inescapable implementation detail when communicating with any driver.
As for this particular situation:
- This DAC has some unique behavior with regard to how it represents its supported formats
- The device is offering us two viable alternatives for handling 16-bit data in a bit-perfect fashion: one with 16bit alignment, and one with 24bit alignment. For a reason that we don’t totally understand, Roon seems to be choosing the second one.
- We have tried all of the similar DACs we do have in house (based on hardware architecture, capabilities, chipset choices, etc) and were not able to reproduce the behavior you’re reporting with any of them.
- Unfortunately, we do not yet have access to a NAIM DAC v1
Despite this, we attempted to change Roon so that it would choose a more specific match for the buffer format in cases like this. We were flying blind, without access to the gear, when making this change a few months ago. Unfortunately, this blind attempt resulted in a regression which impacted several other customers, and necessitated an emergency build to get them working again. From the sounds of it, this didn’t solve the original issue–of course it’s really tough to be confident in a fix like this when we don’t have the necessary equipment to test it.
Mucking around with the low-level code that talks to audio devices is risky and expensive–we do not have every device on earth here to use for regression testing, and even testing with the dozens of devices that we do have is extremely time consuming. We do not go into these areas often, or take it lightly.
Given the context, it’s a stretch to treat a little bit of unnecessary zero-padding–something that is a silent part of nearly all communication with audio devices–as a serious bug. In order to spend a second round of resources on this, we will need to have the gear in front of us so that we can be sure we are not wasting our effort.
So–until we have gear in front of us, this issue is stalled. We tried our best under the circumstances–and in retrospect, it was a bit desperate to attempt to “fix” this blind. In the course of trying to do that, we created inconvenience for others and spent quite a bit of our own resources in the process. We’re going to ping NAIM one last time and see if they want to provide us a unit. For now, we can only reiterate that the stream is indeed bit-perfect, and that we will absolutely revisit this again once we can safely test against this specific device.
2 Likes
Hi Brian,
I did not say that the issue was being ignored but that I hadn’t received any feedback (for 6 months).
Thank you for providing that feedback in a detailed and complete manner.
I appreciate the effort that I now know that you have gone to in attempting to resolve this issue. If even a little bit of this history had been relayed to myself or the original thread then I think that I would not have felt disappointed and anybody else reading the thread would also have been reassured that it was being looked into.
Hopefully Naim will provide you with a test unit as I can’t lend you mine as I would go insane without my music listening in which Roon plays an integral part.
1 Like
@brian, I can happily report that the latest build that you have released (247) has fixed the 44.1/16 issue on my Naim DAC-V1 - thank you very much! 
1 Like