Support for Botic Linux driver

[ppy]

Thanks, Frank.
I was able to use Jack for this task. It works now. But unfortunately Jack does the conversion to a fixed output format.
So a loop alsa device solution would be better. I will study alsa. While given with difficulty.

 

[francolargo]

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.

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.

If TidalConnect is working into Jack, then let's try eliminating Jack and direct the output of TidalConnect to your default Alsa plug instead of creating a virtual device. The syntax is either:

(-X or whatever the TidalConnect output option is..) alsa plug:default'

or leave off the 'alsa'

plug:default

One or the other syntax should work - not sure if the '!' is needed before 'default' - try either way. Also, I suggest the following for your Alsa plugs:

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";

Obviously, best to not specify any output sample rate in the tidalconnect configuration.
If directing to your default plug doesn't work, then perhaps we can create a new virtual 'card'.

Good luck,

Frank

 

[ppy]

Tidalconnect does not see "default" and "sysdefault"

Could not find device: 'default'. Fallback to default device
Valid devices are: 'Botic: - (hw:0,0)' 'sysdefault' 
Could not find a default playback device

Requires hardware emulation of the audio device.
Tidalconnect only sees real devices. Therefore, without loopback, cannot solve this problem.

 

[francolargo]

OK then, loopback it is.

Creating a loopback is quite simple. Here is a good link:
Playing with ALSA loopback devices | Playing with Systems
Simply use 'modprobe snd-aloop'. Then use 'aplay -l' to display the card groups available. When things are working to your satisfaction, you can add 'modprobe snd-aloop' to one or another boot script. To list all of the options within each card group, use 'aplay -L', which is also good for debugging the alsa plugs.

To begin, I suggest you direct TidalConnect to plughw:... or dmix:... Once that works then you can try hw:...

One other important suggestion - *never use tabs in alsa plugs*. Only indent using spaces!

Good luck,

Frank

 

[fernfrost]

Or use the Pure firmware. http://puredsd.ru/Pure.gz
no donations are required.

I really like the minimalistic approach!
Just flashed an sd and running initial testing with spotify connect over usb. Works really well.
Excited to try this with hermes and cronus.

 

[pixelpusher]

I tried the Pure firmware with BBB/Hermes/Cronus but it did not work with the battery backup system.

 

[pixelpusher]

I must have got in on the ground floor as I did not have to pay for the Gentoo Player. I don't know what half the features do but it's been working flawlessly for over a year.

 

[fernfrost]

I tried the Pure firmware with BBB/Hermes/Cronus but it did not work with the battery backup system.

What battery backup system did you use?

 

[pixelpusher]

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.

 

[fernfrost]

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.

But it works fine with Gentoo?

 

[pixelpusher]

But it works fine with Gentoo?

Yes

 

[pixelpusher]

Using the "Pure firmware" with BBB/Hermes/Cronus, music plays way too slow. Can anyone guess what is going on here?
Thanks

 

[coroner21]

Using the "Pure firmware" with BBB/Hermes/Cronus, music plays way too slow. Can anyone guess what is going on here?
Thanks

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.

 

[pixelpusher]

Thanks for the reply coroner21. Yes, the clock divider needed to be set 1:1 then it played music. I preferred the sound of the Gentoo Player though. I did not expect a difference but the sound of the Pure firmware was thin and lacking in the mid bass. Perhaps I will try to contact the developer.

 

[pixelpusher]

Tried the Pure Firmware again and it sounds great. Sorry for jumping to conclusions.

 

[francolargo]

the sound of the Pure firmware was thin and lacking in the mid bass.

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).

 

[mattkuehn]

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?

 

[francolargo]

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?

Seeing no other ideas, perhaps try the HQPlayer forums?