I couldn't get a solution with ALSA so I decided to try it through JACK.
ALSA splits channels into left-right and changes the phase.
Code:pcm.!default { type plug slave { pcm botic-split channels 2 } } pcm.botic-split { type route; slave { pcm "hw:0,0" channels 4 } ttable.0.0 -1; ttable.1.1 -1; ttable.0.2 1; ttable.1.3 1; }
I wanted to build the following chain: TidalConnect->JACK->Alsa(default output)->Botic
I think can try to solve the problem through a virtual alsa loopdevice. But so far, I also do not understand how to do this.
(-X or whatever the TidalConnect output option is..) alsa plug:default'
plug:default
pcm.!default {
type plug
slave {
pcm "botic-split" # added quotes, which works for me inside brackets
channels 2 # this line should be optional but probably doesn't hurt
rate "unchanged" # same comment as line above
}
}
pcm.botic-split {
type route;
slave {
pcm "hw:0,0"
channels 4
}
ttable.0.0 -1;
ttable.1.1 -1;
ttable.0.2 1;
ttable.1.3 1;
}
pcm.plughw.slave.rate = "unchanged";
Could not find device: 'default'. Fallback to default device
Valid devices are: 'Botic: - (hw:0,0)' 'sysdefault'
Could not find a default playback device
I really like the minimalistic approach!
What battery backup system did you use?I tried the Pure firmware with BBB/Hermes/Cronus but it did not work with the battery backup system.
But it works fine with Gentoo?I am talking about the battery mounted on the Hermes. This was to prevent damage to the BBB if power was turned off. This issue was discussed early in the Hermes thread.
Probably wrong clock speeds configured. The firmware assumes that you are running higher speed clocks whereas the mounted clocks have lower frequency or you have the clock divider active... Either set the clock divider to 1:1 / off or (if that is already done) try to adjust the frequency settings for the clocks in the firmware. There should be some parameters probably in bootEnv.txt or similar file.Using the "Pure firmware" with BBB/Hermes/Cronus, music plays way too slow. Can anyone guess what is going on here?
Thanks
Glad all is running well. In the past I've found that widening DPLL bandwidth can help these symptoms (as can improving the wiring into the DAC).the sound of the Pure firmware was thin and lacking in the mid bass.
Seeing no other ideas, perhaps try the HQPlayer forums?Hey All,
Back in 2018 I built two DSCv2's. One of them used the integrated reclocker on the board and the other had an external FIFO and reclocker (Ian Canada's dual XO board).
The one with the integrated reclocker has been going strong since I built it. I just pulled the one with the external reclockers off the shelf and flashed with the latest version of PURE. Whenever I try to send HQPlayer audio NAA logs show:
[/sbin/networkaudiod] (189): push to queue timed out!
[/sbin/networkaudiod] (189): begin disconnection
[/sbin/networkaudiod] (189): ALSA engine stopping...
[/sbin/networkaudiod] (189): ALSA engine stop request...
[/sbin/networkaudiod] (189): clALSAMiniEngine::Stop(): snd_pcm_wait()
[/sbin/networkaudiod] (189): snd_pcm_drain() failed: (-5) Unknown error -5
I did change uEnv to : snd_soc_botic.ext_masterclk=3 snd_soc_botic.clk_44k1=45158400 snd_soc_botic.clk_48k=49152000
My clock signal is coming from the FIFO into the beaglebone on pin 25of P9. I see voltage on that pin so I believe the beaglebone is getting a clock signal.
Any thoughts?