Hey miero,
All this puppy will be doing is streaming music, and allowing control via a tablet or the like, no display attached!
Thankyou Mr Wizard!
Chuz,
Drew.
All this puppy will be doing is streaming music, and allowing control via a tablet or the like, no display attached!
Thankyou Mr Wizard!
Chuz,
Drew.
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. :🙄Thanks.
Not yet, but there will be when we get closer to completion.
If kernel driver is issuing commands to ESS via i2c automatically, based on input rate or format (DOP), based on user defined presets it sounds very good as:
- it is done automatically and does not require user input
- it leaves space for customization for advanced users.
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.
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
For configuration of HW related variables:
- selection of B3/B3SE board
- number of output channels for B3
- on which data input the SPDIF is connected
- ...
- selection of B3/B3SE board
- number of output channels for B3
- on which data input the SPDIF is connected
- ...
using a simple B3 configuration I didn't took those variables in consideration 🙂For configuration of HW related variables:
- selection of B3/B3SE board
- number of output channels for B3
- on which data input the SPDIF is connected
- ...
I love the idea of configuration via the driver!
I think if we do that we should make it optional so that the driver won't behave unexpectedly if people use external I2C control of the DAC.
I think if we do that we should make it optional so that the driver won't behave unexpectedly if people use external I2C control of the DAC.
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.
No it imposes nothing onerous at all. 🙂
Programming the ES9018 filters is pretty simple, it just requires you have the ability to create them. I have done it in the past, but really kind of lost interest in it because it was not designed for in-band filtering.
Programming the ES9018 filters is pretty simple, it just requires you have the ability to create them. I have done it in the past, but really kind of lost interest in it because it was not designed for in-band filtering.
SPDIF Outputs?
Hi Russ,
You posted a picture of the cape on P50 of this thread and I see there are 3 pins labelled SPDIF_1 to 3. Are these SPDIF outputs or what?
Hi Russ,
You posted a picture of the cape on P50 of this thread and I see there are 3 pins labelled SPDIF_1 to 3. Are these SPDIF outputs or what?
Actually they are inputs. 🙂
I will provide more detail on that later, but the gist is that you will have up to 3 channels of SPDIF available to you as well as the I2S or DSD from the BBB.
I will provide more detail on that later, but the gist is that you will have up to 3 channels of SPDIF available to you as well as the I2S or DSD from the BBB.
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
- Home
- More Vendors...
- Twisted Pear
- Building an open embedded audio applicance.