diyAudio

diyAudio (https://www.diyaudio.com/forums/index.php)
-   Twisted Pear (https://www.diyaudio.com/forums/twisted-pear/)
-   -   Support for Botic Linux driver (https://www.diyaudio.com/forums/twisted-pear/258254-support-botic-linux-driver.html)

miero 30th June 2014 06:25 AM

Quote:

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.

twluke 30th June 2014 05:04 PM

Quote:

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.

miero 8th July 2014 06:10 AM

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.

twluke 8th July 2014 06:27 AM

Quote:

Originally Posted by miero (https://www.diyaudio.com/forums/twisted-pear/258254-support-botic-linux-driver-post3984289.html#post3984289)
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. :)

miero 8th July 2014 07:14 AM

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 8th July 2014 07:20 AM

Quote:

twluke, can you shortly summarize previous discussion there please?

translator works somehow, but it messes formatting and many things are not clear to me.
Sure, I'll do it later, once back home tonight.

twluke

twluke 8th July 2014 02:00 PM

> 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

miero 8th July 2014 08:47 PM

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.

twluke 8th July 2014 11:34 PM

> 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

miero 9th July 2014 05:04 AM

> 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-ds...commits/master

It seems that native support for DSD playback has been added just while before my release :-)


All times are GMT. The time now is 08:18 PM.


Search Engine Optimisation provided by DragonByte SEO (Pro) - vBulletin Mods & Addons Copyright © 2020 DragonByte Technologies Ltd.
Resources saved on this page: MySQL 17.65%
vBulletin Optimisation provided by vB Optimise (Pro) - vBulletin Mods & Addons Copyright © 2020 DragonByte Technologies Ltd.
Copyright ©1999-2020 diyAudio

Wiki