Dual Audio Device support with spdif and no 3rd party apps

[Raidfire-SDR]

Before requesting a new feature make sure it hasn't been requested yet.
meta:feature-request

Expected behavior of the wanted feature

This has been touched on before but the request was downgraded to low priority, I would like to raise it again as there are many users being required to use 3rd party software to workaround the lack of feature.
Support for 2 or more Audio devices with at least 1 supporting spdif passthru. gain controls of individual channels would be a big plus for both devices but not essential.

Alternative behavior of the wanted feature

To be able to disable inputs independently

Log file

Even if you think it's not necessary at first, it might help us later to find
possible issues. Make a log file made with -v -v or --log-file=output.txt,
attach it to the issue, and replace this text with a link to it.

[Raidfire-SDR]

I have a modified version of audiodupe.lua and a voicemeeter installation, audio-dupe provides unreliable sync / latency between devices because of the 100ms resolution of ipc calls, we would need to be close to 1ms resolution for decent sync, voicemeeter is stable but still using quite a complex 3rd party engine that for novices would be a challenge to configure, rolling the feature into mpv would allow tighter control over the sync.

My coding skills are rather lacking but i can offer a test environment with 8 multichannel sound devices installed, both windows and linux, professional equipment to measure latency and the ability to turn around a test request within 30 minutes. 24/7.

[ruihe774]

I wonder if it can be achieved using a patchbay tool. I usually use ao_pipewire and use helvum as patchbay. With it I can send audio to multiple devices and can separate channels. I believe there are also patchbays for macOS. I'm not sure if they can work with SPDIF passthru, though.

[Raidfire-SDR]

i have so many audio cards due to my work, each with their own patchbay, this is the exact thing i was wanting to avoid, Voicemeeter does just that but is an extra piece of software to install. configure and maintain, works well but i was looking for an internal solution that can be configured and forgot about, with internal patching and gain controls per channel, per card i have tried most of the 3rd party apps like asiolink, voicemeeter and helvum but it's not an internal solution. If you visit my github, mpv config v2 / scripts audio-dupe.lua does it with a pipe, my own remix of the original script with latency tweaking built in but the internal resolution of the ipc calls between parent and child process means you cant get better than 1/10 of a second control over the latency which is very noticeable, and it also spawns a second window (sync'd child process) which even though asked to close gracefully is touchy about being closed without a system restart sometimes.

If you wish to try this midway thru the script you will need to change the hardcoded child device and look for the 'audio-delay' line to tweak the sync.

[ruihe774]

helvum but it's not an internal solution

IMO I do not consider helvum as an external solution. Graph-based audio systems like PipeWire and CoreAudio have the capabilities to adjust the audio processing graph dynamically. Helvum is just a little GUI built atop the API provided by the audio system. If don't want a GUI, you can manually invoke pw-cli command or write configuration files or scripts to control PipeWire.

i was looking for an internal solution

I think it is difficult. Different devices have different latency. mpv uses device latency to correctly sync video and audio. If the latency of two devices do not match, audio processing node that delays the device with shorter latency is needed. Also, consider the different audio formats of devices... I think implement this feature will indeed reinvent a graph-based audio system inside mpv. (As a joke, then people will ask for a GUI patchbay for mpv...)

[Raidfire-SDR]

MPV excels in the video department, way better than other products which have managed to implement dual audio devices, I generally use mpv on windows so pipewire is something that would only be used in a test rig. What would be nice is if MPV offered an almost out of the box full theater system including the sound, it is just as important to the experiance as the video aspect, latency between cards can be set in config, I measured 19ms between my samsung tv and 8channel studio rack, set 19ms latency delay in voicemeeter and it hasn't needed changing in 9 months.

I'm not a coder but i'll have a look if you can point me towards the right source code for the windows audio, there is always a way to do something it just requires the will to provide the best product.

If the audio is such a bind to implement how about improving the ipc resolution by at least a factor of 10, I understand it would add to the over head but again we could have a high or low res setting in the config file, the audio-dupe could be considered as a finished solution ready for rollout if the resolution was improved.

[ruihe774]

I'm not a coder but i'll have a look if you can point me towards the right source code for the windows audio

It's not just about Windows audio; it's about the entire ao architecture. You can have a look at ao_get_delay in audio/out/buffer.c and its usages in core.

A solution may be to implement a meta ao driver that send audio data to multiple backend ao drivers. (If you ask me, I will name it ao_tee.) It has to handle latency differences and format differences internally and report a unified latency and format to core. It is theoretically doable, but first there needs to be someone interested in implementing it.

[Raidfire-SDR]

This looks beyond my skill set so I'll throw it back to the devs who do know C, you talked about someone with interest, i think we need to find the interest given the number of people around the net asking for this and the vast number of other projects that have done this successfully, audio is just as important to the experience but reading through historical posts it has been overlooked from day 1 and seen as a side product to the video and daunting as it maybe, it could be time for a full rethink based on functionality not simplicity to code and a complete rewrite from the ground up, especially given the mess a few weeks ago with broken spdif.

[t-8ch]

IMO you seriously underestimate the amount of work this would be, especially in a cross-platform way.
I wouldn't hold my breath but instead try to work with your native audio system.
Those who could implement such a solution most likely would just use the native solution.

[Raidfire-SDR]

A search in issues yields 109 results for dual audio, google throws up huge threads devoted to the subject, it's not a non issue or low priority for the users.

we only have to go a couple of pages into issues to find others asking, please and when, few deeper and even more people asking, visit reddit and av forums people crying for the feature, it's been going on for years, how about some focus to get it implemented instead of shying away from the task. It's about time a little project management was brough into play, various aspects of mpv are in a disastrous health, with multiple devs remixing each others code, nobody quite understanding what state something is in, we often see 'code not updated since xyz date' how about assigning single devs to single tasks, not just what they are interested in but working through the huge list of meta-requests this is one of the oldest meta requests out there and since day 1 it's been rejected due to complexity whist competitor devs got their heads down, solved the problem and released code years ago.

At least lets deal with the pos resolution, it was talked about for several years and was upgraded to a meta-request a month ago, let's get it down to 1ms not 100 then pipes might be viable.
#13695

All these comments of 'find a dev who's interested' 'under estimate the complexity' all seem like nobody is interested in the challenge of either fixing issues or meta requests if they don't involve video.