That does not mean the clocks must be limited to audio, Just preferably three clocks on board, Which are multiples of 44.1, 48, (44.1*48*integer) and whatever is necessary for dsd1024 or higher. With i2s or aes output built in and preferably multiple power source inputs. Probably some caps to isolate the noise from the CPU, etc. I hav just been having a tough time finding a SBC which does not require reclocking. If Audio clocks are too slow for computation needs, then integer multiples can be used. How is that going? Thanks everyone. Any new inexpesive SBCs within the past year or so / dacs/adcs worth looking at? At prices below $100?
I love cirrus. I also have an amanero. I also love sabre. AKM, not my sound imho.
Got another project, ukranian el84 with c-cores as OTs, but need to get some work done before writing about that one.
Philip
I love cirrus. I also have an amanero. I also love sabre. AKM, not my sound imho.
Got another project, ukranian el84 with c-cores as OTs, but need to get some work done before writing about that one.
Philip
Last edited:
Can we make a linux sbc with music clocks?
If music clocks are not fast enough for the O/S computation, we use integer multiples. Why other companies use such incompatible frequencies, I don't understand. There is enough of a neiche market for the audio centered sbc. We could have i2s, AES, or whatever the majority thinks/knows is best. It would be nice to have as much included in the unit so that switching DAC chips involves the least hardware additions possible, at minimum, of course, leaving room for additional tweaks according to user needs/prefs/. I do not want to collect money. I want a trusted senior member to take that responsibility should they accept, and there is sufficient interest. Hope this is possible. Aspiring Philip
If music clocks are not fast enough for the O/S computation, we use integer multiples. Why other companies use such incompatible frequencies, I don't understand. There is enough of a neiche market for the audio centered sbc. We could have i2s, AES, or whatever the majority thinks/knows is best. It would be nice to have as much included in the unit so that switching DAC chips involves the least hardware additions possible, at minimum, of course, leaving room for additional tweaks according to user needs/prefs/. I do not want to collect money. I want a trusted senior member to take that responsibility should they accept, and there is sufficient interest. Hope this is possible. Aspiring Philip
Last edited:
There is the Twisted Pear Audio/Miero solution which takes a standard Beaglebone Black and imposes correct musical master clock frequencies on it's i2s output using external reference clocks.
I am yet to try it but there are many people using it. The beauty of such an approach is that the same clock can run the dac so there is only one synchronous time domain for the whole system.
I am yet to try it but there are many people using it. The beauty of such an approach is that the same clock can run the dac so there is only one synchronous time domain for the whole system.
IMO this is the correct approach. No reason to relate audio clocks to clocks of the main system. The I2S hardware uses DMA for reading samples from RAM at its own pace anyway.
So how about using ssd for ram? and can we not create ram of custom frequencies? 2116.8=44.1*48 can we use ssd as ram or else over/underclock ram? It must be possible to make audio purposed ram or under/overclock, or else go the ssd route... Surely the demand is overwhelming for the specific clock speeds. If sd could be used instead, that would avoid the approximations that plague ram due to the random processes the construction is based on.
If anyone can get the group buy set up, this will be the website with enough enthusiasts. Can we pinpoint and address the needs to make it happen? that would be true audio bliss amd dreams come true. What route may be feasible if any?
I will pitch in for one share. wuld like aim to to keep a certain amount of the protocols open source, although construction may need to be designated or pioneered by one manufacturer who has the guts, the knowhow, and the facilities. Open source is great but someone we trust can be equivalent or even better, if its a cooperative project.
I would like to have the experts take charge and make those decisions. I have a few ideas, all revolving around keeping things modular/ upgradable. Beaglebone sounds like a good bet. that is 100 percent open source and a tough unit.
BTW, am using an ancient amanero at the moment. Great unit.
If anyone can get the group buy set up, this will be the website with enough enthusiasts. Can we pinpoint and address the needs to make it happen? that would be true audio bliss amd dreams come true. What route may be feasible if any?
I will pitch in for one share. wuld like aim to to keep a certain amount of the protocols open source, although construction may need to be designated or pioneered by one manufacturer who has the guts, the knowhow, and the facilities. Open source is great but someone we trust can be equivalent or even better, if its a cooperative project.
I would like to have the experts take charge and make those decisions. I have a few ideas, all revolving around keeping things modular/ upgradable. Beaglebone sounds like a good bet. that is 100 percent open source and a tough unit.
BTW, am using an ancient amanero at the moment. Great unit.
You can design audio HATs running as I2S master.
Basically the audio interface will provide the quality clock. That's what e.g. Allo does with most of their products.
Another solution is to run a reclocker HAT.
The SBC becomes somewhat irrelevant in both cases.
That'll also allow stable SRs up to 384k in most cases!
Be careful with niche SBCs!!
Firmware, kernel and software support are usually limiting factors. Many DIY projects fail (sooner or later) because of this.
Basically the audio interface will provide the quality clock. That's what e.g. Allo does with most of their products.
Another solution is to run a reclocker HAT.
The SBC becomes somewhat irrelevant in both cases.
That'll also allow stable SRs up to 384k in most cases!
Be careful with niche SBCs!!
Firmware, kernel and software support are usually limiting factors. Many DIY projects fail (sooner or later) because of this.
Last edited:
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.