INTERACT FORUM
More => Old Versions => JRiver Media Center 27 for Linux => Topic started by: ths61 on January 19, 2021, 09:36:08 pm
-
Does the Linux port have an analogous MC WMD sound redirect feature from other Linux apps (e.g. play Spotify through the Linux MC distro) ?
Is there a list of functional and non-functional Linux audio features (e.g. volume protection, master volume, etc.) ?
Thanks much.
-
Does the Linux port have an analogous MC WMD sound redirect feature from other Linux apps (e.g. play Spotify through the Linux MC distro) ?
No.
Is there a list of functional and non-functional Linux audio features (e.g. volume protection, master volume, etc.) ?
Thanks much.
It's the same as the Windows version.
-
Does the Linux port have an analogous MC WMD sound redirect feature from other Linux apps (e.g. play Spotify through the Linux MC distro) ?
No.
Not the answer I was looking for, but thanks for the quick answer.
I would like to be able to play Spotify/Pandora/etc. through MC's convolver if any Linux workarounds or new audio features become available to bring the feature sets on par.
I tried installing v26 on 64-bit Debian 10 with a real time kernel and the new install procedure was straight forward.
-
You can only do it in Windows unfortunately, since the WDM driver is a Windows-only feature (in fact WDM stands for Windows Driver Model).
-
You can only do it in Windows unfortunately, since the WDM driver is a Windows-only feature (in fact WDM stands for Windows Driver Model).
I understand what WMD means, but Unix/Linux is famous for its pipes, tees and redirections of I/O streams. One would think it would fit right at home in Linux. =)
-
I understand what WMD means, but Unix/Linux is famous for its pipes, tees and redirections of I/O streams. One would think it would fit right at home in Linux. =)
Yeah you'd think it would be possible. Like, it's trivial to create a dummy ALSA device on Linux that can be set as the system default and will redirect all system audio to a pipe (all it takes is editing two config files). I got my system set up to do that for a while, and I could have all my Linux software system-wide (including MC if I wanted) output to the pipe and even redirect that pipe to a file to record local playback, but I just found no good way to get MC to take a pipe as input in real-time. Given that MC can open and play remote audio streams like web radio, you'd think reading info from a local pipe would be theoretically possible (and may have fewer complicating factors).
I briefly toyed with writing script to redirect my dummy alsa device pipe to a series of files(i.e. changing to a new file after some short interval) and then use MCWS to programmatically add the completed chunk files to the now playing list in real-time to get a slightly delayed WDM-like experience, but I never managed to get sub-second chunking/adding to work well at all, and the whole thing was pretty wonky. It would have been totally unusable for video or games, so I never got very far down the line.
I suspect that it may be possible one day!
-
...
I briefly toyed with writing script to redirect my dummy alsa device pipe to a series of files(i.e. changing to a new file after some short interval) and then use MCWS to programmatically add the completed chunk files to the now playing list in real-time to get a slightly delayed WDM-like experience, but I never managed to get sub-second chunking/adding to work well at all, and the whole thing was pretty wonky. It would have been totally unusable for video or games, so I never got very far down the line.
I suspect that it may be possible one day!
Have you seen these ?
Using modprobe to add snd-aloop to the kernel to create an ALSA loopback, then recording the ALSA stream from the loopback using ffmpeg ? It might give some ideas.
https://unix.stackexchange.com/questions/310164/create-virtual-device-in-asoundrc-file (https://unix.stackexchange.com/questions/310164/create-virtual-device-in-asoundrc-file)
https://unix.stackexchange.com/questions/263813/how-do-i-create-virtual-alsa-device-from-which-i-can-record-everything-that-is-p (https://unix.stackexchange.com/questions/263813/how-do-i-create-virtual-alsa-device-from-which-i-can-record-everything-that-is-p)
https://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html (https://www.alsa-project.org/alsa-doc/alsa-lib/pcm_plugins.html)
-
Yeah you'd think it would be possible. Like, it's trivial to create a dummy ALSA device on Linux that can be set as the system default and will redirect all system audio to a pipe (all it takes is editing two config files). I got my system set up to do that for a while, and I could have all my Linux software system-wide (including MC if I wanted) output to the pipe and even redirect that pipe to a file to record local playback, but I just found no good way to get MC to take a pipe as input in real-time. Given that MC can open and play remote audio streams like web radio, you'd think reading info from a local pipe would be theoretically possible (and may have fewer complicating factors).
I briefly toyed with writing script to redirect my dummy alsa device pipe to a series of files(i.e. changing to a new file after some short interval) and then use MCWS to programmatically add the completed chunk files to the now playing list in real-time to get a slightly delayed WDM-like experience, but I never managed to get sub-second chunking/adding to work well at all, and the whole thing was pretty wonky. It would have been totally unusable for video or games, so I never got very far down the line.
I suspect that it may be possible one day!
I've though about this occasionally and thought it seems like something that should be doable. I'm just not sure how in MC to handle the input.
If you use file->open on the pipe does that work?
Where should it feed into MC?
-
I've though about this occasionally and thought it seems like something that should be doable. I'm just not sure how in MC to handle the input.
If you use file->open on the pipe does that work?
Where should it feed into MC?
why can't you just use some alsa input directly? isn't it going to be logically the same as asio line in?
-
I've though about this occasionally and thought it seems like something that should be doable. I'm just not sure how in MC to handle the input.
If you use file->open on the pipe does that work?
Where should it feed into MC?
Opening the pipe as a file did not work last time I tried it. I think MC expects the file input to be a fixed size which obviously doesn't work with the pipe.
I agree that listening to ALSA input directly (like the "open live" option on Windows) seems like a cleaner solution than piping it in. Depending on how its implemented it might not even require any user configuration at the OS level (audacity, for example, seems to be able to loopback/monitor arbitrary ALSA sinks with no changes to my system configs).
-
Opening the pipe as a file did not work last time I tried it. I think MC expects the file input to be a fixed size which obviously doesn't work with the pipe.
I agree that listening to ALSA input directly (like the "open live" option on Windows) seems like a cleaner solution than piping it in. Depending on how its implemented it might not even require any user configuration at the OS level (audacity, for example, seems to be able to loopback/monitor arbitrary ALSA sinks with no changes to my system configs).
Do you know anything about how the format is determined?
-
Do you know anything about how the format is determined?
I would expect you could query alsa or pulse in a similar way to how you find out what formats output devices support (i.e. alsacap or pactl list).
For a pulse specific example, "pactl list" shows if a given sink is running and what output format it's currently using. It also shows various "sources" that are monitors of the various output sinks. For example, if I set my audacity input to "monitor of <name>" then I get whatever is being output to the sink <name>, and pactl list shows me what the current output format is for the sink I'm monitoring. So you could probably directly parse what you need out of pactl or if you need more info maybe figure out how pactl is getting its answers?
I'm sure there are similar methods for direct monitoring in alsa using alsacap/aplay/snd-aloop, but when I got my pipe set up I mostly just piped it into aplay which seemed to automagically know what to do with it. I don't have a clear idea of how to programmatically get the output format of a running stream directly at the ALSA layer (i.e. pulse can tell me about it, but that doesn't help where pulse isn't installed).
-
this hook might help? https://github.com/scripple/alsa_hook_hwparams
I've noticed camilladsp (http://"https://github.com/HEnquist/camilladsp") has support for processing being driven by a pipe so possibly you can look at that code for inspiration.
not sure if you can create a null sink (for pulse) or aloop (for alsa) on behalf of the user or whether it would be something the user has to configure. If it has to be the user then imv that's fine, seems preferable to have a working loopback that takes some manual config vs no loopback at all.
-
Played a bit, but not sure if JRiver is able to pick it up.
Adding a virtual soundcard is the easy part.....
Tested with Qobuz, which uses the virtual card.
but then :-\
pacmd load-module module-null-sink sink_name=JRiver
pacmd update-sink-proplist JRiver device.description=JRiver
pacmd load-module module-loopback sink=JRiver
(https://image.prntscr.com/image/4en0gVs1TfyLQkb3iw2u1A.png)