More > JRiver Media Center 27 for Linux
Is there an analogous MC WMD sound redirect feature from other apps ?
bob:
--- Quote from: mwillems on January 29, 2021, 11:11:53 am ---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).
--- End quote ---
Do you know anything about how the format is determined?
mwillems:
--- Quote from: bob on January 29, 2021, 12:37:50 pm ---Do you know anything about how the format is determined?
--- End quote ---
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).
mattkhan:
this hook might help? https://github.com/scripple/alsa_hook_hwparams
I've noticed 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.
Wheaten:
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 :-\
--- Code: ---pacmd load-module module-null-sink sink_name=JRiver
pacmd update-sink-proplist JRiver device.description=JRiver
pacmd load-module module-loopback sink=JRiver
--- End code ---
Navigation
[0] Message Index
[*] Previous page
Go to full version