Hi Acko,I do not understand your question,can you rephrase please.I have a Amenero-FIFO Ian-DAC pcm 1704,very happy to use a BB for source which will replace my PC and Amanero .Now, with the FIFO, is that the Cape Russ is nessecaire or not ?
Thank.
Miero,
With the Biotic cape providing the appropriate family clock to the BBB, do you think it might handle medium-quality SoX up-sampling? I'm hoping we can experiment with bypassing the DAC chips' built-in digital filter and using a better-tuned one in software, inspired by John Swenson's work on the Bottlehead DAC and the Community Squeezebox replacement which uses the Wandboard imbedded processor system.
TIA!
Greg in Mississippi
Last edited:
Upsampling to multiples of frequency is much less CPU hungry, but there is also another BBB limit ~2.3MB/s data throughput.
It is able to play 384/32 data on one channel 1.5MB/s, but two channels with 3MB/s does not work.
There is chance that 384/24 stereo would be fine, but I've not tested it yet (driver must be tuned a bit).
But you would need to have those files prepared, the on-the-fly encoding probably will not work.
It is able to play 384/32 data on one channel 1.5MB/s, but two channels with 3MB/s does not work.
There is chance that 384/24 stereo would be fine, but I've not tested it yet (driver must be tuned a bit).
But you would need to have those files prepared, the on-the-fly encoding probably will not work.
Thanks for that info, Miero.
I do suspect that there will be useful off-DAC-chip in-software OSF solutions for the ESS DACs that won't require up-sampling to 384/32. As I remember, the PCM5142 DAC John Swenson chose for the Bottlehead and Community Squeezebox Replacement units ONLY shuts off the OSF when you feed it a 384/32 signal (and a quick scan of that datasheet seems to confirm that... BTW, that is BY FAR the largest datasheet I've seen for a DAC!).
But you CAN turn off the OSF via I2C with the higher-end ESS DACs... and even the lowly ES9022 & ES9023 may benefit from alternately-filtered inputs, even though you can't turn off their built-in filter.
Greg in Mississippi
I do suspect that there will be useful off-DAC-chip in-software OSF solutions for the ESS DACs that won't require up-sampling to 384/32. As I remember, the PCM5142 DAC John Swenson chose for the Bottlehead and Community Squeezebox Replacement units ONLY shuts off the OSF when you feed it a 384/32 signal (and a quick scan of that datasheet seems to confirm that... BTW, that is BY FAR the largest datasheet I've seen for a DAC!).
But you CAN turn off the OSF via I2C with the higher-end ESS DACs... and even the lowly ES9022 & ES9023 may benefit from alternately-filtered inputs, even though you can't turn off their built-in filter.
Greg in Mississippi
You won't benefit from the FIFO if you use the cape, as everything will already be clocked only to the audio master clocks. No reclocking required.
All the FIFO would do is add latency.
Of course you can leave the FIFO, but it won't be doing much good.
Now lets please drop the discussion of third party modules - keep the focus on what we are actually developing.
What would you say about ALSA mixer control that switches between Filter Slow Roll-Off, Fast Roll-Off and Over-Sampling Bypass?
I think a simple text based (let's say port hifiduino app to python- later the output/input of the app can be accessible via web or whatever) application for setting ESS chip via i2c will be more convenient rather than letting ALSA doing this.
Another thing to take in consideration will the effort needed to include this mod in the main branch of ALSA. If the mod will be let out of the main branch it will mean that the end user need to compile ALSA etc etc ...
I would suggest that given that storage is pretty cheap these days, offline upsampling would offer two benefits for those who wish to negate the deleterious effects of the onboard filters.
Non-realtime upsampling using a good upsampler - (the Isotope one, or R8brain Pro or the one in Reaper) - is likely to yield superior sonics.
No additional CPU load (other than bitrates) on the BBB.
So you still get the benefit of moving the filter effects way out of band without the big hit on the realtime processing at replay time. You just need a bigger hard drive.
Non-realtime upsampling using a good upsampler - (the Isotope one, or R8brain Pro or the one in Reaper) - is likely to yield superior sonics.
No additional CPU load (other than bitrates) on the BBB.
So you still get the benefit of moving the filter effects way out of band without the big hit on the realtime processing at replay time. You just need a bigger hard drive.
No, the ALSA controls are provided by kernel driver which you will need to use either way. And you can control it using standard alsa tools, or any fancy mixer you choose.
Currently ALSA needs to be recompiled only if you want to play 352800kHz and 384000kHz and DSD128 too. Because it has hardcoded upper limit for 192000kHz.
EDIT2: reverted EDIT1
Currently ALSA needs to be recompiled only if you want to play 352800kHz and 384000kHz and DSD128 too. Because it has hardcoded upper limit for 192000kHz.
EDIT2: reverted EDIT1
Last edited:
BIIISE clock and cape
In using the BIIISE with the cape, do we disable the clock in the BIIISE and feed MCK from the cape or the BBB? Or the cape clocks are only used by the BBB and the BIIISE keeps its 100mhz clock active? If the cape is clocking both, will it matter that the clock to the BIIISE will be a cable with a different length than the path of the cape clocks to the BBB? Sorry if the answer is obvious, but I'm confused! Thanks.
In using the BIIISE with the cape, do we disable the clock in the BIIISE and feed MCK from the cape or the BBB? Or the cape clocks are only used by the BBB and the BIIISE keeps its 100mhz clock active? If the cape is clocking both, will it matter that the clock to the BIIISE will be a cable with a different length than the path of the cape clocks to the BBB? Sorry if the answer is obvious, but I'm confused! Thanks.
Hey Miero,
So would the player software ie volumio have to recompile alsa with the work you are doing regards dsd etc so the os would a) know to use the cape clocks and b) be able to play 352/384khz natively? I havent met a resampler/upsampler i like yet so would prefer to play it straight though at its original rate. Thats the main eeason I want to record in dsd.
Just making sure I keep up!
Thanks Miero for your efforts!
Chuz,
Drew.
So would the player software ie volumio have to recompile alsa with the work you are doing regards dsd etc so the os would a) know to use the cape clocks and b) be able to play 352/384khz natively? I havent met a resampler/upsampler i like yet so would prefer to play it straight though at its original rate. Thats the main eeason I want to record in dsd.
Just making sure I keep up!
Thanks Miero for your efforts!
Chuz,
Drew.
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.
PET-240:
a) clocks frequencies/GPIO switches/etc will be possible to change in the device tree file (board configuration file) without recompiling kernel or alsa -- but it will be preconfigured for Botic Audio cape, so no need to change this unless doing some clock mods or so
b) yes, I've reported this earlier -- http://www.diyaudio.com/forums/twis...embedded-audio-applicance-15.html#post3871359 -- however, this is currently very CPU/data hungry and it is near the BBB limits, so one must be careful when wants to use it (e.g. no HDMI display and so...)
a) clocks frequencies/GPIO switches/etc will be possible to change in the device tree file (board configuration file) without recompiling kernel or alsa -- but it will be preconfigured for Botic Audio cape, so no need to change this unless doing some clock mods or so
b) yes, I've reported this earlier -- http://www.diyaudio.com/forums/twis...embedded-audio-applicance-15.html#post3871359 -- however, this is currently very CPU/data hungry and it is near the BBB limits, so one must be careful when wants to use it (e.g. no HDMI display and so...)
Although I'm very busy lately, I'm following this thread looking for updates. Thank you very much for your effort miero, I confirm that your work will be integrated in RuneAudio when released.
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.