[PROBLEM] Brief 'buzz' when skipping to next track

[Tim Curtis]

The challenge in debugging these types of issues is that a dev would need the exact same hardware to try a repro and then if one can be produced, investigate what might be happening.

[dr.diem]

Yes, I hear you   If some debug logging might help I would be more than happy to follow your guidance in enabling whatever output you need and providing log files, or indeed installing a debug version of moode with custom logging.

In the meantime I've contacted Schiit for their input and will report back.

[TheOldPresbyope]

@dr.diem

Sorry for the redundant question I posted. I was called away from my laptop as I was writing it and I posted it when I returned...after you'd already posted you were going to ask Schiit.
 
Does your "buzz" occur only when manually changing tracks and not when MPD advances automatically from one track to the next in its queue?

I note this remark by the MPD maintainer in response to a MPD issue about "clicks"

When you manually change the track, MPD stops the PCM, and restarts it when it has decoded enough of the next track. Some drivers/devices may emit a small pop noise when you stop the PCM. This is not MPD's fault - MPD just uses standard ALSA API calls.

Similarly, the Schiit USB interface may unhappy when the PCM is stopped while MPD begins decoding and buffering the next track. All that is taking place out of moOde's sight.

Just a guess, mind you, I don't have any Schitt gear to poke at. 

Regards,
Kent

[dr.diem]

@dr.diem

Sorry for the redundant question I posted. I was called away from my laptop as I was writing it and I posted it when I returned...after you'd already posted you were going to ask Schiit.
 
Does your "buzz" occur only when manually changing tracks and not when MPD advances automatically from one track to the next in its queue?

I note this remark by the MPD maintainer in response to a MPD issue about "clicks"

When you manually change the track, MPD stops the PCM, and restarts it when it has decoded enough of the next track. Some drivers/devices may emit a small pop noise when you stop the PCM. This is not MPD's fault - MPD just uses standard ALSA API calls.

Similarly, the Schiit USB interface may unhappy when the PCM is stopped while MPD begins decoding and buffering the next track. All that is taking place out of moOde's sight.

Just a guess, mind you, I don't have any Schitt gear to poke at. 

Regards,
Kent

No worries Kent!

Yes, the buzz only occurs when manually skipping forward to the next track or, I've discovered, when scanning forwards within the same track. It does not, however, occur when skipping back to the previous track, which is what gives me hope that the issue is not between mpd, the kernel and the Schiit USB interface. It does not occur at all when the source is a laptop running Linux (different architecture and USB transceiver, so far from directly equivalent) nor from Volumio on an rPi (a much closer equivalent).

Could you provide a reference for that comment from the mpd maintainer? It might help me to see what discussions have been had over there about mpd running on an rPi feeding PCM out over USB, and I can inquire into whether mpd behaves any differently when skipping forwards or backwards.

Cheers,

Ian

[Nutul]

Just to add to the soup...

I have a RPi4 4GB, attached to an external USB audio interface (a Focusrite I2I which ATM I use only as a DAC, and a good one, according to my ears).
I also play only FLACs together with their CUEs (usually 1 CUE => 1 FLAC, but multi-CD albums => 1 CUE + multiple FLACs).

Not the slightest hint of a glitch when either sweeping back/forth, or skipping prev/next track.
TTYTT "I do not always skip tracks, but when I do..."

Have you checked the buffer sizes, he output mode, the volume type... in moOde's audio settings?

Don't know... just guessing, as I don't experience the problem.


Cheers, Al.

[dr.diem]

Thanks Al,

None of those settings makes a difference unfortunately. My one new data point is that playback from Spotify is unaffected, but I've of course no idea how the audio routing differs from mpd running on the box locally.

Ian

[Geojanitor]

Ian
have not heard any more about this issue in a while so thought I'd touch base. I was on the Schiit website lately and noticed that they had a firmware update for the Bifrost 2,

Bifrost 2/64 and Bifrost 2 Current Firmware: Bifrost 2 C0094, D0109
Release Date: 8/11/2022

Release notes: Required for Bifrost 2/64. Can be used on Bifrost 2 as well. Allows swapping of Bifrost 2 and Bifrost 2/64 analog cards without changing firmware. Enables NOS (non-oversampled) mode on all Bifrost 2 as well as Bifrost 2/64. Supersedes 7/25/2022 version; addresses sample rate glitch noted in some systems. 

Note the last line. Didn't know if you had updated. Thought I'd reach out.

Dave

[dr.diem]

Thanks for the followup Dave - it's very kind of you. I actually already have this firmware release installed. The 'rare sample rate glitch' in the release notes refers to a different issue wherein the wrong sample rate is selected under certain specific circumstances and has very different symptoms. It was a reasonable summation of two plus two though on your part

I would have made peace with this being a firmware incompatibility between the Allo streamer USB out and Schiit's custom USB implementation, but since the issue doesn't occur when using the Spotify audio renderer that hypothsis clearly isn't correct. MPD is definitely in the frame, though it is similarly not solely to blame because as I said earlier in the thread when I use a Lenovo laptop running MPD on Linux as the source the issue is not reproduced. It would seem to be a three-way incompatibility between rPi/MPD/Schiit USB. This being the case, the number of affected folks out there isn't high enough it seems to be able to solve the problem. Its a real shame but I have had to give up on finding a solution