• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Support for Botic Linux driver

Jump to Latest
M

miero

Member
Joined 2011
Ray, a bitrate of the DSD512 is equivalent to a bitrate of the PCM 705.6/768kHz and it does not work on the BBB and IMHO it never will, because it is too much for the BBB. I'm not sure if the Ethernet is able to transfer 6MB/s required for such rates.

The 768kHz rates in the Botic driver are now enabled just for a testing purposes.
 
nautibuoy

nautibuoy

Member
Joined 2010
miero said:
Ray, a bitrate of the DSD512 is equivalent to a bitrate of the PCM 705.6/768kHz and it does not work on the BBB and IMHO it never will, because it is too much for the BBB. I'm not sure if the Ethernet is able to transfer 6MB/s required for such rates.

The 768kHz rates in the Botic driver are now enabled just for a testing purposes.
Click to expand...

Thanks miero, you may well be right but I want to push this a little further still wrt DSD512.

I'm using a dedicated audio network and the Win10 performance monitoring on the HQPlayer computer shows an almost flat line for the Ethernet loading at around 48mbps so it looks to be holding up. Also DSD512 is only loading the BBB CPU to around 35-40%, which is also promising. I know performance is rather more complex than two simple measurements but my setup is actually 'playing' DSD512 but with the static-like noise.

One aspect I'm not sure about is whether the ESS9018 can actually process DSD512; the only mention I've seen of a 9018 dac with a reference to a DSD512 capability was in a dual mono 9018 chip setup, which presumable halves the load on each individual 9018?

So, I'm thinking the next step is to feed the DSD to a DAC that I know can definitely handle DSD512 rates and the obvious way to do that is with a 'no-dac' low-pass filter approach. As I don't want to disrupt the project I've been using so far, that will mean I need to acquire an additional isolator/reclocker to experiment further, so it may take a little time to assemble a prototype.

I must give PCM768 a try too.

Ray
 
G

gentlevoice

Member
Joined 2007
Paid Member
@Ray:

On just a couple of tracks (PCM and DSD) I heard a low level static noise for maybe 10-20secs, which just faded away. On replaying the same tracks the noise was gone? Mostly silences between selections were silent but just occasionally there was a little background noise, again like static. Its entirely possible that this is unrelated to the BBB/Botic/NAA combo.
Click to expand...

Hi Ray ... just a comment: I've experienced what I assume could be similar noises with DSD (and also PCM actually) when my computer was unable to process the DSD data OR my clock somehow was out of sync with the data stream. I reckon that what happened was that the data stream clock and the clock itself was like two watches each having their own "synchronicity" and thus the distances between the rise/fall times of the two signals differed. It sometimes led to a very static/ticking noise.

An idea ...

Cheers,

Jesper
 
nautibuoy

nautibuoy

Member
Joined 2010
gentlevoice said:
...I've experienced what I assume could be similar noises...
Click to expand...

Thanks Jesper.

In the scenario you describe would the reclocker get everything 'synced' before the data stream is handed off to the DAC?

I'm thinking I have too many unknowns/variables in the 'equation' at the moment. I've already alluded to the 9018 and not being sure if it is DSD512 capable but at the other end is my HQPlayer PC, which gets heavily loaded when upsampling to DSD512 - maybe a good starting point would be to obtain a DSD512 recording.

Ray
 
G

gentlevoice

Member
Joined 2007
Paid Member
In the scenario you describe would the reclocker get everything 'synced' before the data stream is handed off to the DAC?
Click to expand...

Hi Ray ... Yes, ideally it would. But in my experience things sometimes are "mysterious" as I currently have my Amanero & my DDDAC clock running without "sync", i.e. they both run at their own pace. Yet on PCM (currently 192 kHz - haven't had the time to fix this) there's no noises at all (but the sound is less precise than it is with a sync'ed clock/data signal) ... However, when moving to 384 kHz the noises return (I'm pretty sure it's not computer related) and I reckon this is due to inconsistent clock timing intervals on the data & clock signals.

Just FYI, I'm pretty sure the 9018 is capable of DSD512. I once communicated with a person who made this work. Don't know how he set it up though ...

maybe a good starting point would be to obtain a DSD512 recording.
Click to expand...

Hmmm... if you find this I would be quite interested in hearing about it ;-)

Cheers,

Jesper
 
T

twluke

Member
Joined 2012
Ray wrote to miero:
nautibuoy said:
Are you considering another patch to explore the optimisation of the buffer further?
Click to expand...

As Miska wrote in the previous message, the period size is expected to be proportional to the value of buffer time on the HQP setting (705.6 x [buffer time on HQP] in case of upsampling to DSD512).

So, with 250 ms buffer time, which I believe will cause almost no xrun errors on the side of BBB/Botic/NAA, HQP is expecting the period size to be 705.6 x 250 = 176400. But the actual period size provided by the current patch appears somehow limited to 131072 as shown in the log below:

Code: 
[/usr/sbin/networkaudiod] (495): ALSA active channels: 2
[/usr/sbin/networkaudiod] (495): ALSA number of periods: 2
[/usr/sbin/networkaudiod] (495): ALSA period times: 5 - 185760
[/usr/sbin/networkaudiod] (495): ALSA period sizes: 4 - 131072
[/usr/sbin/networkaudiod] (495): ALSA period time: 185759
[/usr/sbin/networkaudiod] (495): ALSA period size: 131072
[/usr/sbin/networkaudiod] (495): ALSA engine started at: 22579200 (22579200)
[/usr/sbin/networkaudiod] (495): enter streaming mode
[/usr/sbin/networkaudiod] (495): ALSA engine running...
Despite of this limitation, I've been so far quite satisfied with the SQ of upsampled DSD512 sources from HQP via BBB/Botic/NAA, experiencing only a few xrun errors, once in 20-30 minutes during playing music. However, if the patch can deal a little bit more with the current requirement from HQP, it will be almost perfect.

BTW, shown below are BCK (DSD CLK) waveforms from BBB/Botic/NAA when playing DSD sources upsampled to 128, 256 and 512. Even with DSD512, the waveform appears not bad, doesn't it? ;)

Regards,


 

Attachments

  • waves.png
    waves.png
    25 KB · Views: 244
T

twluke

Member
Joined 2012
nautibuoy said:
twluke, can I just confirm that, for your DSD512 experiment, you are using cronus/hermes/rhea fitted with 45/49MHz oscillators?

Ray
Click to expand...

Exactly. I have each of B3 and B3SE connected to BBB/Hermes/Cronus, both with 45 and 49 clocks. Shown below is the B3 in the case, which playing DSD512 as of taking this picture.

Here is a very good news. With each system, I noticed that there had been no xrun errors when playing DSD512 sources with duration of at least one hour, though I wrote that the error might occur once in 20 to 30 minutes in the previous post. Below is the entire log of playing a CD rip from the beginning to the end. Please notice there has been no xrun errors.

Code: 
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): start 22579200/1/2 [dsd]
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): Set channels: 2 (2)
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): Set sampling rate: 22579200 (22579200)
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA engine starting...
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA channels: 2 - 8
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA active channels: 2
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA number of periods: 2
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA period times: 5 - 185760
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA period sizes: 4 - 131072
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA period time: 185759
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA period size: 131072
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA engine started at: 22579200 (22579200)
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): enter streaming mode
Jul 12 21:06:22 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA engine running...
Jul 12 21:17:01 arm CRON[741]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Jul 12 21:37:27 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): data read was short (418688 < 602112)!
Jul 12 21:37:27 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): begin disconnection
Jul 12 21:37:27 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA engine stopping...
Jul 12 21:37:27 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA engine stop request...
Jul 12 21:37:28 arm networkaudiod[527]: [/usr/sbin/networkaudiod] (527): ALSA engine stopped
Of course, there is one problem. After getting started with playing music, a kind of background noise also appears. This is faint and similar to the sound of wave at the shore, probably associated with the process of DSD locking. This noise soon disappears but reappears at some point, though there was no regularity. The situation is common through both B3 and B3SE.

As my B3 and B3SE are both configured with the DAC clock as it is, the problem may be associated with ASRC function on the side of DACs, though this assumption may not be correct.

Also, I have a Botic board for BBB assembled along with the original instruction by miero at http://bbb.ieero.com/. The board shown below includes 2 sets of 2:1 MUX for DSD/PCM and 44.1/48 clock switching with an isolator (ISO7640fm) for the output of I2S/DSD signals. A CCHD-957 22.9752 and an Epson 24.576 clocks are used for this system. The output connects to B3SE via Teleporter.

This board also works as BBB/Botic/NAA and playing DSD512 is quite stable for a few hours at least. I didn't notice any xrun error and also there has been no complication of noisy background noticed in 45/49 clock systems.

I can not explain why such a difference between 22.5/24.9 and 45/49 clocks can occur in terms of background noise. I'll be happy if there is anyone who can explain it.

Regards,
 

Attachments

  • b3.jpg
    b3.jpg
    402 KB · Views: 247
  • custom.jpg
    custom.jpg
    439.8 KB · Views: 246
nautibuoy

nautibuoy

Member
Joined 2010
twluke said:
Exactly. I have each of B3 and B3SE connected to BBB/Hermes/Cronus, both with 45 and 49 clocks. Shown below is the B3 in the case, which playing DSD512 as of taking this picture.
Click to expand...

Thank you twluke. Some interesting projects you have there too.

I'm looking to buy a Cronus/Hermes/Rhea setup to experiment further and I can now proceed, when Cronus is back in stock, with the standard 45/49MHz oscillators.

THanks for the additional info on DSD512 playback as well.

Cheers

Ray
 
T

triodehunter

Member
Joined 2014
i2s-lines delayed

Hello Miero,

I managed to get my system working. BBB > Botic5 > Hermes > Cronus > DDDac. I am using external clocks (http://www.diyaudio.com/forums/digi...ow-phase-noise-jitter-crystal-oscillator.html). The system works flawless.

Thank You very much for Your fine piece of art!

As I am using a multichannel all-horn-system, delay lines are essential.

My question is whether I can use three of that four i2s-lines delayed by Botic OS. If that is possible basically, I think the real challenge might be to tell the system the needed delay in msec respectivly fractions of msec valid for all possible sample rates.

I am not interested in digital crossovers whatsoever. So there is no need for that. The signal should not be modified in any way, just delayed.

Regards,
Hans
 

Attachments

  • 1.jpg
    1.jpg
    1.1 MB · Views: 258
  • 2.jpg
    2.jpg
    956.7 KB · Views: 242
You must log in or register to reply here.
Top Bottom