We’ve reproduced this. It’s very finicky–@vova got a machine into a broken state like this (not sure if by accident or on purpose) this morning, and we can make the problem happen repeatedly, but only on that machine.
I’m moderately convinced that if we reboot the broken machine, the problem will go into hiding again.
Using the broken machine, we put the problem under the microscope. It is definitely a driver-level bug when this happens:
Roon is providing audio at one sample rate (lets say 44.1k) and the driver is playing it at a higher rate (probably 88.2 or 96k if it sounds like double time). The problem description basically nails down what’s happening to a degree: some part of the system is confused about what the current sample rate is.
Our dialogue with the ASIO driver in the current production software looks like this:
Roon: Hey driver, initialize for me
Driver: Ok
Roon: Hey driver, switch your sample rate to 44.1k.
Driver: Ok, I did it
… time passes with no further communication …
Roon: here’s some 44.1k audio
Driver: Ok
Driver: (plays in double-time)
(???)
My first thought was to change the dialogue so we double-check the sample-rate right before playing the audio. That way if something external messed with the driver or hardware state during that time interval, we had a chance to double-check and correct the problem, but this didn’t work.
Roon: Hey driver, initialize for me
Driver: Ok
Roon: Hey driver, switch your sample rate to 44.1k.
Driver: Ok, I did it
… time passes with no further communication …
Roon: lets double-check your sample rate. Is it still 44.1k?
Driver: Yup.
Roon: here’s some 44.1k audio
Driver: (plays in double-time)
However, if we tell the driver the sample rate immediately before playback, basically like this, the problem goes away:
Roon: Hey driver, initialize for me
Driver: Ok
Roon: Hey driver, switch your sample rate to 44.1k.
Driver: Ok, I did it
… time passes with no further communication …
Roon: Hey driver, switch your sample rate to 44.1k.
Driver: Ok, I did it
Roon: here’s some 44.1k audio
Driver: (plays correctly)
I’m not a huge fan of sending extra commands to the driver, but it looks like that’s going to be our workaround. I worry that somewhere out there, there’s a driver that will behave badly in light of these redundant commands, or do some crappy 2-5s sample-rate switching routine with lots of clicks and pops, or something.
I wonder if this is some sort of power-saving thing–like maybe the device forgets its sample rate because the USB system goes into a low power mode or something, and the driver forgets to tell it the right value after it wakes up. Just a guess…but it feels like the kind of thing that might be happening here.
We’re pushing out a new production build shortly. This workaround will be in it. It will be interesting to see if this completely solves the problem.