Hi Miero,
I did more tests with my cape and the power off/ shut down things. To monitor BBB shut down and turn off the BAT line after shutdown is complete I use now a simple 8 pin micro controller
Depending on the details of your cape - you shouldn't need any controller at all. I found with my cape I needed none.
Are you using BBB rev B(C) or some older revision? Or do you have mounted a network storage?
The P9_14 should be enabled at the audio driver initialization and should be pulled down right before the power off. But I'm not aware of any pulses on that pin generated by BBB. But I'll recheck.
Can you check serial output of the BBB during shutdown sequence? Please proceed only if you have TTL (3.3V) serial adapter for this, otherwise BBB will be damaged.
The P9_14 should be enabled at the audio driver initialization and should be pulled down right before the power off. But I'm not aware of any pulses on that pin generated by BBB. But I'll recheck.
Can you check serial output of the BBB during shutdown sequence? Please proceed only if you have TTL (3.3V) serial adapter for this, otherwise BBB will be damaged.
BAT off
Hi Russ,
yes we don't need an additional controller for BBB power off!!!
But I use those because the BAT is unloaded up to min. 3.4V after every shutdown (possibly), I prefer a full BAT at every time >4V because I had some BBB shut down problems, while BAT is loading again after startup (just in worst case stress tests!).
"AndyCape" is really overpowered in this case, my simple PIC12F1571 detects just the CPWR_EN, give me some feedback with a LED on the front panel and turns BAT line off 15s after shutdown is complete. Thats all.
Regards.
Depending on the details of your cape - you shouldn't need any controller at all. I found with my cape I needed none.
Hi Russ,
yes we don't need an additional controller for BBB power off!!!
But I use those because the BAT is unloaded up to min. 3.4V after every shutdown (possibly), I prefer a full BAT at every time >4V because I had some BBB shut down problems, while BAT is loading again after startup (just in worst case stress tests!).
"AndyCape" is really overpowered in this case, my simple PIC12F1571 detects just the CPWR_EN, give me some feedback with a LED on the front panel and turns BAT line off 15s after shutdown is complete. Thats all.
Regards.
Are you using BBB rev B(C) or some older revision? Or do you have mounted a network storage?
The P9_14 should be enabled at the audio driver initialization and should be pulled down right before the power off. But I'm not aware of any pulses on that pin generated by BBB. But I'll recheck.
Can you check serial output of the BBB during shutdown sequence? Please proceed only if you have TTL (3.3V) serial adapter for this, otherwise BBB will be damaged.
I'm using BBB rev B, rev C is my backup. Yes a network storage is mounted.
What P9 pin do you mean with serial output to check?
Oh, with mounted network storage this might be issue #3 from the list. This one will be fixed in the next release. (( I'm sorry for this ))
Please retry with unmounted storage to verify if the 3.3V is present even "after shutdown".
Btw, serial console accessible using serial adapted on the "debug serial header", check BBB_SRM.pdf for more info.
Please retry with unmounted storage to verify if the 3.3V is present even "after shutdown".
Btw, serial console accessible using serial adapted on the "debug serial header", check BBB_SRM.pdf for more info.
Some hints for trying OSF-bypass mode of ES9018:
Unprocessed audio data (DxD/PCM) is not suitable for playback in this mode. There are several conditions that should be fulfilled to not generate unwanted aliases in the output signal (they are visible in the FFT).
Following steps are needed for correct playback:
- resample audio to 352.8/384kHz
- apply brickwall low-pass filter to 1/16 of sampling rate
Check my old post for more info: http://www.diyaudio.com/forums/digi...e-reference-dac-8-channel-77.html#post3868811
Unprocessed audio data (DxD/PCM) is not suitable for playback in this mode. There are several conditions that should be fulfilled to not generate unwanted aliases in the output signal (they are visible in the FFT).
Following steps are needed for correct playback:
- resample audio to 352.8/384kHz
- apply brickwall low-pass filter to 1/16 of sampling rate
Check my old post for more info: http://www.diyaudio.com/forums/digi...e-reference-dac-8-channel-77.html#post3868811
I finally managed to get the botic driver working on Fedora 21 ARM. If there is interest I'll put up the RPMs.
Bring on the cape(s)! 🙂
Bring on the cape(s)! 🙂
Yes, I did a (cross) recompile with the Fedora 21 kernel SRPM and created a new patch for botic support based on your patches. I also had to modify the dts file to free up the needed resources for botic.lintweaker: did you recompile the kernel? do you have some patches to check/review/integrate?
Now that I am this far I can added/test some planned features like support for DSD_U32_BE sample format.
Who knows what is this? :-D
I'm going to assemble it and verify if everything works well with BBB and the driver ... and I hope the (positive) results will be very soon! 🙂
So happy it arrived safe and sound. Now we can get some momentum. 🙂
Good luck!Who knows what is this? :-D
I'm going to assemble it and verify if everything works well with BBB and the driver ... and I hope the (positive) results will be very soon! 🙂
Quick status
Assembled and tested basic functionality -- seems to work great, but no serious listening today.
The ribbon cable will be replaced with direct connection later...
Assembled and tested basic functionality -- seems to work great, but no serious listening today.
The ribbon cable will be replaced with direct connection later...
Attachments
Last edited:
miero, just wanted to thank you for your efforts with the Botic distro.🙂
I'm currently listening to my Buffalo IIISE DAC and it is sounding truly excellent. I2S data is obviously arriving via a BBB with your software but dare I mention that I'm using an Acko SO3 to clock the BBB, reclock the I2S data and as masterclock (I have 90 & 98MHz clocks on the SO3) for the IIISE. It all works seamlessly and, as I've said, sounds excellent. I'm sure those waiting for the Hermes/Chronos combo won't be disappointed.
Anyway, thanks again and take a well deserved pat on the back.
Ray
I'm currently listening to my Buffalo IIISE DAC and it is sounding truly excellent. I2S data is obviously arriving via a BBB with your software but dare I mention that I'm using an Acko SO3 to clock the BBB, reclock the I2S data and as masterclock (I have 90 & 98MHz clocks on the SO3) for the IIISE. It all works seamlessly and, as I've said, sounds excellent. I'm sure those waiting for the Hermes/Chronos combo won't be disappointed.
Anyway, thanks again and take a well deserved pat on the back.
Ray
With the success of my network renderer/dac build mentioned above I would like to network enable my office headphone amp by replacing its USB input with a BBB/Botic. The DAC is an ES9023 so no onboard lossless volume control. I enquired about whether a lossless volume control was possible/available in mpd, which is at the core of miero's botic software, a little while back;
http://www.diyaudio.com/forums/twisted-pear/258254-support-botic-linux-driver-37.html#post4179297
to which miero kindly responded. I've started to have a look at miero's reply;
But the last programming I did was in Cobol well over 20yrs ago and with my advancing years I'm struggling a bit (or should that be 16bits!); can anyone help me out with a summary suitable for one who is less gifted in this area.
Thanks muchly
Ray
http://www.diyaudio.com/forums/twisted-pear/258254-support-botic-linux-driver-37.html#post4179297
to which miero kindly responded. I've started to have a look at miero's reply;
The MPD seems to implements this properly for each sample format.
You can check it at the end of this file: master/mpd.git -
So the quality depends on the current output format (can be forced in mpd.conf).
But the last programming I did was in Cobol well over 20yrs ago and with my advancing years I'm struggling a bit (or should that be 16bits!); can anyone help me out with a summary suitable for one who is less gifted in this area.
Thanks muchly
Ray
Ray, it should be enough to change volume in the MPD... no need for advanced programming. The referenced code does this properly 🙂
Ray, it should be enough to change volume in the MPD... no need for advanced programming. The referenced code does this properly 🙂
Thanks miero. My mention of my former programming skills was just to explain just how out of date I am; I wasn't entertaining the idea of doing any programming!😱
So, the code delivers lossless volume control for different bit depths?
Ray
- Home
- More Vendors...
- Twisted Pear
- Support for Botic Linux driver