• Disclaimer: This Vendor's Forum is a paid-for commercial area. Unlike the rest of diyAudio, the Vendor has complete control of what may or may not be posted in this forum. If you wish to discuss technical matters outside the bounds of what is permitted by the Vendor, please use the non-commercial areas of diyAudio to do so.

Building an open embedded audio applicance.

Jump to Latest
#581
ChrisMmm said:
My understanding is that as long as you, or the player software you are using, use ALSA services all is well. I use Squeezelite under Debian and the drivers miero has written work fine.
Click to expand...

The reason it works with Squeezelite is that it supports streaming native DSD to it from LMS and it does not convert to DoP on output unless you add the -D option. This may not be the case for other players, such as MPD, that either convert to PCM by default or converts to DoP when enabled even though it uses ALSA. Where can I find Miero's drivers so I can test things here?
 
#587
Russ White said:
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. 🙂
Click to expand...
Sorry if this has been asked before but I haven't seen it mentioned.
The only way to do synchronous reclocking, AFAIK, is to feed the audio clock signal back from the Cape to the BBB. As there are two audio clocks only one is enabled at any one time, depending on which speed family is being handled by the BBB. To decide which speed family the audio file belongs to requires that the beginning of the audio file is first read & the speed family ascertained. Can the BBB change audio clock (provided by the Cape) on the fly to accommodate this scenario or is there some other clever trick?
 
#589
miero said:
Yes, the BBB chooses the clock which will be used to play audio data. This clock goes as input for the BBB and optionally also to the DAC if it is configured to the synchronous mode.
Click to expand...

OK, thanks
The BBB allows for changing this input clock while powered up & operating - i.e on the fly?
As far as I understand how this would operate - The start of the audio file will have to be read to establish the speed family, the correct clock then enabled & its signal used as input to the BBB - all this has to happen while the audio file is still being read - so some buffering is required. Am I correct in my assumptions?
 
Last edited:
#593
miero said:
Both clocks have OutputEnable pin which can be easily controlled by BBB. Setting this pin to low disables the clock.
Click to expand...

Yes, that's simple - I don't mean that - I mean that the BBB will have to have started reading the audio file before it knows which of the two clocks to enable. This enabled clock then has to be used as input to the BBB. Changing clocks on the fly like this is not instantaneous & so some delay/wait period is involved (some parts of the system has to be shutdown & restarted with the new clock, perhaps?). While this is happening the audio file still has to be read in real-time or some buffer used which can deal with this wait period.
 
#597
If you need to control a nucular power plant, it is a good idea to use software certified for realtime operation. After all, it would be slightly annoying if reactor safety scram was slightly delayed because Windows Update decided to install a "critical update" during a tsunami.

In the case at hand ... mmmmmh, it would probably be useless. RT kernel just adds some RT features to Linux, like guaranteed minimum execution slices and latencies. If your music doesn't skip while using the regular kernel, you can be pretty sure it won't skip either on the RT kernel. But if it doesn't skip in the first place...
 
You must log in or register to reply here.
Top Bottom