I am currently looking at designing this in two stages.
Botic version 1.0 with just the features described already:
What I hope to do is to get something in the hands of users sooner rather than later, so that the community can give feedback right away - thus improving the next edition.
Cheers!
Russ
Hi Russ,
Is there a way to sign up for the v1? I'd be happy to be o beta tester on it. :
Thanks.
Hi Russ,
Is there a way to sign up for the v1? I'd be happy to be o beta tester on it. :
Not yet, but there will be when we get closer to completion.
This is easily done, I have already installed to control parameters and volume. I only miss a decent interface for that.
D.
Well, I just used the I2C drivers and wrote a couple of scripts to send the command through I2C. This is not through the I2S connection, but through the I2C connection. I find very beneficial to have both part implemented, for volume control and for all the other parameters. But maybe you are looking at a smarter way to do it.
D.
D.
Yes, the kernel driver will send I2C commands to Sabre32 DAC according the user settings (volume, filters, DPLL, quantizer,...) and played data (e.g. set if 16/20/24/32 bits in I2S data stream are valid). Also it will deactivate SPDIF autodetect when playing starts, and activate back when it stops.
Later I'd like to also include reading the DIP switches on the Buffalo for default values on the power-on.
Later I'd like to also include reading the DIP switches on the Buffalo for default values on the power-on.
what is the reason for this feature, cannot kernel driver initialise the SABRE on load with an user defined preset? like the hifiduino firmware using arduino as i2c sabre controler.
thanks
Yes, three variants are planned:
1) without I2C link - usable with any DAC that supports I2S(/DSD):
- HW parameters configurable via device tree file
2) I2C link to ES9018
- HW parameters configurable via device tree file
- ES9018 control via I2C (I2S format, volume, filters, DPLL, quantizer,...)
- ALSA mixer support
2) I2C link to Buffalo DAC
- HW parameters configurable easily via DIP switches (friendly use)
- ES9018 control via I2C (I2S format, volume, filters, DPLL, quantizer,...)
- ALSA mixer support
1) without I2C link - usable with any DAC that supports I2S(/DSD):
- HW parameters configurable via device tree file
2) I2C link to ES9018
- HW parameters configurable via device tree file
- ES9018 control via I2C (I2S format, volume, filters, DPLL, quantizer,...)
- ALSA mixer support
2) I2C link to Buffalo DAC
- HW parameters configurable easily via DIP switches (friendly use)
- ES9018 control via I2C (I2S format, volume, filters, DPLL, quantizer,...)
- ALSA mixer support
Miero,
Thanks for your efforts. One thing I've never been able to program are the custom filters. Please give it a try.
Seems having the control code in user space (and outside the pretty complex audio path) is a better place, running at a lower priority. (Based on my limited knowledge of unix)
Thanks for your efforts. One thing I've never been able to program are the custom filters. Please give it a try.
Seems having the control code in user space (and outside the pretty complex audio path) is a better place, running at a lower priority. (Based on my limited knowledge of unix
)
Last edited:
What I see from my implementation using the i2c module is only that you have an extra module loaded. The commands generate messages only when called. So I do not see any overhead either way.
I never really posted this as I thought it was trivial, like the remote command implementation. The latter I am not sure if it affects the sound. I would say no, but I did not do a deep analisys of the resources allocated for that.
If somebody is interested I am happy to give more details.
D.
I never really posted this as I thought it was trivial, like the remote command implementation. The latter I am not sure if it affects the sound. I would say no, but I did not do a deep analisys of the resources allocated for that.
If somebody is interested I am happy to give more details.
D.
Hello Russ et al, thanks for the work you're doing with this. I've dabbled with streaming via a RPi and the DLNA network interface on my home cinema amp but this is just the sort of quality implementation I've been waiting for and I plan to invest in a Buffalo DAC IIISE on the strength of it (when they become available again!).
How will the cape connect to the DAC board, or more specifically, do I need to order the UFL connector option with the DAC?
As a DLNA/UPnP user (BubbleUPnP is my preferred controller) I don't anticipate using Volumio as I want a common look and feel to controlling all my renderers. I use GMediaRenderer_resurrect on my RPi (with Raspbian) to good effect and would like to use that on Debian on the BBB but will that exclude me from all the good work being done here on drivers etc?
Thanks again.
Ray
How will the cape connect to the DAC board, or more specifically, do I need to order the UFL connector option with the DAC?
As a DLNA/UPnP user (BubbleUPnP is my preferred controller) I don't anticipate using Volumio as I want a common look and feel to controlling all my renderers. I use GMediaRenderer_resurrect on my RPi (with Raspbian) to good effect and would like to use that on Debian on the BBB but will that exclude me from all the good work being done here on drivers etc?
Thanks again.
Ray
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.