Open flatmax opened 4 years ago
For example, this code will correctly align input channels as they are expected to be : https://github.com/flatmax/gtkiostream/blob/master/test/ALSAFullDuplexMinScan.C
It can be compiled like so : g++ -I . -I include -I/usr/include/alsa -I/usr/include/eigen3 -lasound -lsox -lfftw3 test/ALSAFullDuplexMinScan.C -o test/ALSAFullDuplexMinScan
Where gtkiostream is setup as in this post to the email list : https://lists.audioinjector.net/pipermail/people/2020-March/000019.html
I need a work around for channel alignment for the output. I implemented a change like the full duplex program above. I simply looked to see where the empty buffer was then change channel mapping in my mixer. Input channels always work correctly in my software. But the outputs are now scrambled. I would like to know if there is a way to determine which channels are which on output so I can auto configure the mapping.
This it seems is an issue. Once you descramble the input using that code, is there any constant relationship between the output and the input channels ? Also I assume you are using the overlay's non_stop_clocks too (dtoverlay=audioinjector-addons,non-stop-clocks=true )
There does not seem to be a relationship between input scramble and output. I have seen the input was not scrambled and the output is and visa-versa. Yes I am currently running non-stop-clocks. That does not seem to make any difference for me now. My ap always gets the input unscrambled correctly. But output is correct only after reboot, but not after restarting my program. I have to reboot to get output unscrambled after my program has run the first time.
It has been reported that synchrony is lost between capture and playback. For example : https://github.com/Audio-Injector/Octo/issues/20
This seems to be a problem event once the modules have been reloaded. This problem was not originally evident.
One concept for fixing this is to have a process keeping the synchrony. This process will never stop processing even though it doesn't record and outputs zeros to the playback device.
For example, if the dmix and dsnoop devices were used they could be opened a second time from different applications. The base process which was started first would never stop and thus synchrony would be maintained. The problem here however is that dmix and dsnoop are asynchronous devices.
Another approach which is purely software based is to do an analysis at startup of the audio application. This analysis would search for the audio channels which are always 0. These channels are channels 7 & 8. The audio software could then remember the channel alignment and realign the audio data knowing which channels are 7 & 8.