I need to read up on that one. Opto is a must for me but I think one can just add a e.g. TOTX-147 on the coaxial output - right?
Also, I don't want SRC... it should be transparent to the injected FS - need to check if thats possible.
Otherwise looks good - thanks!!
//
Also, I don't want SRC... it should be transparent to the injected FS - need to check if thats possible.
Otherwise looks good - thanks!!
//
The easiest would be to just add something like this: https://www.amazon.com/Optical-Tendak-Bi-Directional-Converter-Splitter/dp/B06XCTGZFT
or
Nedis Digital audio-omvandlare S/PDIF - TosLink - Digital audio-omvandlare S/PDIF till TosLink
The xmos chip doesn't do any SRC, just outputs what you give it.
or
Nedis Digital audio-omvandlare S/PDIF - TosLink - Digital audio-omvandlare S/PDIF till TosLink
The xmos chip doesn't do any SRC, just outputs what you give it.
Yes.
"Audio Input Connectivity: 4 x AES/EBU or SPDIF (8 channels) on DB-25 connector (Tascam pinout).
Asynchronous sample rate conversion to convert AES-EBU input rates (32 to 216 kHz) to the recording rate configured in your software."
I will not use it like this I suppose, but rather:¨
"Connectivity
4 x AES/EBU or SPDIF (8 channels) on DB-25 connector (Tascam pinout).
Sample rate defined by the playback rate in software (44.1~192k)"
I.e. I will use the 8 outs, not the 8 in...
//
"Audio Input Connectivity: 4 x AES/EBU or SPDIF (8 channels) on DB-25 connector (Tascam pinout).
Asynchronous sample rate conversion to convert AES-EBU input rates (32 to 216 kHz) to the recording rate configured in your software."
I will not use it like this I suppose, but rather:¨
"Connectivity
4 x AES/EBU or SPDIF (8 channels) on DB-25 connector (Tascam pinout).
Sample rate defined by the playback rate in software (44.1~192k)"
I.e. I will use the 8 outs, not the 8 in...
//
Last edited:
More pictures here: MiniDSP U-DIO8 Digital interface 8 channels AES/EBU 192KHz USB 7.1 - Audiophonics
Looks like there is one SRC chip for each spdif input, so whatever you send in gets converted to the selected samplerate. That's probably the only way to sync four independent spdif inputs to one common rate.
Looks like there is one SRC chip for each spdif input, so whatever you send in gets converted to the selected samplerate. That's probably the only way to sync four independent spdif inputs to one common rate.
4 x SRC4382 Minidsp U-DIO8 USB to AES Converter Review | Page 2 | Audio Science Review (ASR) Forum That is real ASRC, not the USB async mode which is not any resampling.
Given this I might lean towards the RME (without having seen any 3rd party meas). But I think the miniDSP is OK also depending a bit on the DAC solution. An other player is the computing platform för Camilla... My Mac Mini or a Pi4? Pi lets the RME out of the game as I understand it...
//
//
I know, i know... i didn't even finish up the repos. i use now for Superplayer, there are something there which is not needed.
So if i understand correctly, i should make a new branch and call it say' squeezelite source or like and upload the sourcecode there? For squeezelite with the changes i made to it along with the makefile for compiling on an Raspberry Pi? Right???
Jesper.
You can actually do all of in using the github web interface. Start by forking squeezelite to your account. Go to GitHub - ralph-irving/squeezelite: Lightweight headless squeezebox player for Logitech Media Server and click "Fork" up in the right corner.
Once the fork is ready, go to the Code tab of your fork and click the branch select dropdown (should say "master"). In the box, type a name for your new branch, for example "control_camilladsp". Then click the option "Create branch: control_camilladsp from master".
This should create the new branch and switch to it. Now you can use the web editor to insert your changes. Just click a source file in the list to view it. Then there is a little pen symbol up in the right corner of the frame that shows the contents. Click this to open the editor. Once you are done, scroll down to the bottom to save. Type a short description of the change, select "Commit directly to the control_camilladsp branch." and commit.
Once you are done, you can easily compare the new branch with master, to get a clear view of the changes. Click "Pull requests" and create a pull request from control_camilladsp to master (in your fork, not ralph-irving/squeezelite yet!). Then the changes show up under "Files changed" of the pull request.
If I want to pipe both input and output, in CamillaDSP underlinux I can easily get the input setting in the yml
capture:
filename: /dev/stdin
playback:
filename: /dev/stdout
Now, how can I do this on windows? I did some research but ended up with nothing
capture:
filename: /dev/stdin
playback:
filename: /dev/stdout
Now, how can I do this on windows? I did some research but ended up with nothing
I need to use pipes (which exists on win), you can pipe input and output like sox | Camilla | sox, but camilladsp needs a path to be specified, the problem Is that on Linux everything Is a file, on Windows It is not like that. I'd like to avoid virtual interfaces.
The fact that stdin/stdout are available as "files" in linux, macOS etc means I got the stdin/out functionality for free when I added the File device. Of course this trick doesn't work on windows, there I would need to do something specifically for stdin/out. There are special functions for reading and writing to stdin/out that I would need to use instead of reading/writing to files. That is probably a more elegant way also on the various unix-based systems. I'll add it on the todo list. I haven't looked at how big changes are needed to the code, and I also have to think a little about how to change the config options to include this.
Probably yes (but I never use WSL so I don't know for sure). It gets a bit clunky since CamillaDSP will need to be compiled under WSL, meaning cargo and rustc must also be installed there.