• 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

However, here is one question. With the default channel configuration (-1), the sidedness of L-R channel on PCM is normal but is reversed on DSD play.

That is expected if you just replace LRCK with DATA1. To preserve channel order on ES901x you need to "use" DATA0 instead of LRCK and DATA1 instead of DATA0.

The Botic cape will do such remapping for 4 channels.
 
That is expected if you just replace LRCK with DATA1. To preserve channel order on ES901x you need to "use" DATA0 instead of LRCK and DATA1 instead of DATA0.

Thank you for this somewhat intrigued info. At first I thought reassignment of pins for this channel setting was quite easy but realized that switching back to PCM with this setting was not that easy.

After several trials, I ended up with using a pair of 2-pole switches with the simultaneous polarity between DSD and PCM selections: one connecting to the DAC DATA (DSD1) from P9_30 on PCM and P_41 on DSD; the other one connecting to the DAC LRCK (DSD2) from P9_29 on PCM and P_30 on DSD, by sharing the P9_30 output between both switches.

Might have been a tedious work and maybe still missing better solution, but, anyway, I could obtain the correct sidedness of stereo channels on both DSD and PCM plays for now.
 
FYI: there are long discussion threads in Japanese about this driver at ‚Ý‚Ý‚¸�H–[ŒfŽ¦”Â

I'd welcome if someone from there would report discovered issues here. Or any tips or tricks that could improve the sound.

Thanks.

Thanks for introducing this particular thread. I'm one of them participating to it. Google translator will be happy for helping you. :)
 
twluke, can you shortly summarize previous discussion there please?

translator works somehow, but it messes formatting and many things are not clear to me.

for example there was some complaint that playing 48kHz with oscillator for 44kHz does not work... it might be if external is always on, because on-board oscillator is used in that case

also there was some trick to mpd conf that fixes playback... I did not find what is needed to be changed...
 
> twluke, can you shortly summarize previous discussion there please?

Well, there are at least three users including me trying this boticized 3.15.1 kernel with driver in this Japanese discussion group: me with BIIISE and the other two geeky people with another ES9018 DAC (aitlaboTOPpage). They are using an external clock of 22.5792 MHz from the same vendor (D-Clock Neutrino) for 44.1K and occasionally on-board clock for 48K. BTW I'm using external clocks for both 44.1K and 48K from the MCLK output of Amanero Combo384.

Anyway, as of this writing, all users have basically succeeded in playing PCM and DSD sources and are enjoying this I2S/DSD-mediated music playing.

> for example there was some complaint that playing 48kHz with oscillator for 44kHz does not work... it might be if external is always on, because on-board oscillator is used in that case

Well, we are well aware of it and, with ext_masterclk=1 setting, one of the users recommended to disconnect the external clock on playing 48K. So it may not be a major problem.

> also there was some trick to mpd conf that fixes playback... I did not find what is needed to be changed...

No need to worry about it ;). It's for the GMPC setting as an MPD client and has nothing to do with the architecture of the current DSD-native MPD.

BTW, the other person wanted to know the reason to add the following lines in case of "SampleFormat::FLOAT:" in the MPD patch:

+ case SampleFormat:SD:
+ return SND_PCM_FORMAT_DSD_U8;

As for the test samples provided in the .img file, below is our impression on average.

8in8_-_05_-_Ill_Be_My_Mirror.mp3 and test_44k1_16b.flac: on 44.1K clock, they sounded awful with distortion (personally I noticed these files play well with Audirvana+ on my Mac, though).

test_48k_16b.flac and test_96k_24b.flac: no problem with 48K clock; sounded clearly.

test_dsd64.dff and test_dsd128.dff: both stopped playing a few seconds after start, cannot complete the sequence or return to the start.

Other than these test files one user pointed out that 44.1K flac files sound quite noisy with an external clock for 44.1K, though those 48K and 96K flac files played well. This is also the case with Apple lossless (m4a) 44.1K files which sound quite distorted with a 44.1K external clock. So, we are all expecting future improvement in playing these 44.1K flac or m4a sources.

Well, this is a sort of summary for now. I hope this can be of help for your future work. Anyway, we are always praising your great work. Thank you.

twluke
 
twluke:

>> for example there was some complaint that playing 48kHz with oscillator for 44kHz does not work... it might be if external is always on, because on-board oscillator is used in that case
> Well, we are well aware of it and, with ext_masterclk=1 setting, one of the users recommended to disconnect the external clock on playing 48K. So it may not be a major problem.

alternative option would be to set ext_masterclk=3 ... so the on-board clock will be disabled (and 48K data played with 44K clock)

I'll add new "external clock for 44k1 only (no support for 48k)" option for ext_masterclock for easier testing with just 44k1 clock.

>BTW, the other person wanted to know the reason to add the following lines in case of "SampleFormat::FLOAT:" in the MPD patch:
>+ case SampleFormat:SD:
>+ return SND_PCM_FORMAT_DSD_U8;

This is needed for declaring output format for DSD playback. Previously this MPD-dsd has embedded dsd into pcm (DoP).

> test_dsd64.dff and test_dsd128.dff: both stopped playing a few seconds after start, cannot complete the sequence or return to the start.

There is just 10 seconds of music to test DSD. And not correctly terminated thus it might cause described issue. You can try files from High Resolution Music DOWNLOAD services .:. FLAC in free TEST BENCH - these should play without issues.

> 8in8_-_05_-_Ill_Be_My_Mirror.mp3 and test_44k1_16b.flac: on 44.1K clock, they sounded awful with distortion (personally I noticed these files play well with Audirvana+ on my Mac, though).
> Other than these test files one user pointed out that 44.1K flac files sound quite noisy with an external clock for 44.1K, though those 48K and 96K flac files played well. This is also the case with Apple lossless (m4a) 44.1K files which sound quite distorted with a 44.1K external clock. So, we are all expecting future improvement in playing these 44.1K flac or m4a sources.

I do not have external clock, I'm just using on-board one. But I think this should sound well with external clock. If you can re-try use the ext_masterclk=3 (in the uEnv.txt) to exclude the possibility that two clocks are enabled at same time.

You can try also if the output is not resampled via following command (approx.):
cat /proc/asound/card0/pcm0p/sub0/hw_params

Thanks for the report.
 
> I'll add new "external clock for 44k1 only (no support for 48k)" option for ext_masterclock for easier testing with just 44k1 clock.

It might be convenient for testing 44.1K sources in the future. Thank you.

> >+ case SampleFormat:SD:
> >+ return SND_PCM_FORMAT_DSD_U8;

> This is needed for declaring output format for DSD playback. Previously this MPD-dsd has embedded dsd into pcm (DoP).

I appreciate this explanation but I still have one question. Last day, I tried to play DSD sources with a conventional MPD version only supporting DoP (0.18.11, compiled under an ordinary debian rootfs) on this boticized environment. This went well and I couldn't find any difference between your DSD-native MPD and this DoP-only MPD in playing files. That is one of the reasons to raise a question about the patch.

> There is just 10 seconds of music to test DSD. And not correctly terminated thus it might cause described issue.

Thanks for this info.

> I do not have external clock, I'm just using on-board one. But I think this should sound well with external clock.

Yes, we confirmed that your application "play" does good job in dealing with flac 44.1K files but the current MPD can not, even with ext_masterclk=3. So there may be still something to be fixed, though I'm not sure whether this problem is deriving from MPD or ALSA.

Regards, twluke
 
Last edited:
> This went well and I couldn't find any difference between your DSD-native MPD and this DoP-only MPD in playing files. That is one of the reasons to raise a question about the patch.

https://github.com/lintweaker/mpd-dsd-018/commits/master

It seems that native support for DSD playback has been added just while before my release :)
Native DSD playback support is not finished yet. I have a BBB on order to be able to test.
 
Questionable:
- MPD playback quality ... better to use command line tool play
Hi miero,
I see that you are using a "helper" audio playback application, instead of MPD's internal playback engine.
So you might be interested to investigate BruteFIR which a few years ago was alleged to be the best "audiophile" commandline audio player application -
BruteFIR
Setup is a bit messy; it requires a default configuration file; /root/.brutefir_config
as explained here -
BruteFIR
which includes the name and location of the audio file to be played, in this format -
device: "file" { path: "/mnt/sdb1/MUSIC/mymusic.wav"; };
Once configured, all that's required is to run the command "brutefir".
 
This might be caused by different issue - the size of HW buffers in the BBB audio interface which seems to be much more smaller (just a few samples) than most of common audio card (PCI and USB).

In the mpd.conf on demo image I've set "period_time" of ALSA output to the smallest value, but there might be more things to be tuned.

There was no problem with command line tools play and aplay, which are using default ALSA values. So I assume the MPD can be fixed too.

BruteFIR is not relevant in that case :)
 
Out of curiosity, I retrieved the source file from the URL above and compiled it under the boticized 3.15.1 kernel running on BBB.

After installation, I compared the binary with the one by miero, playing several DSD128 sources and found that the sound quality was quite close each other, permitting only slightly better resolution with the lintweaker version.

Just my two cents.