search

jakemoroni / audio_async_loopback

Real-time S/PDIF PCM/AC3 capture and playback
GNU General Public License v3.0
26 stars 7 forks source link

Stereo channels are flipped #7

Closed Shados closed 1 year ago

Shados commented 1 year ago

When taking uncompressed stereo PCM from my Hifime S2 Digi, audio_async_loopback appears to flip the left and right channels. Playing back directly from the device has the channels oriented correctly, so it's not a device issue. Haven't tested AC3 channel layout yet, but this doesn't bode too well :).

jakemoroni commented 1 year ago

Hey @Shados

Are the left and right channels permanently swapped or are they alternating during playback?

Either case will definitely break AC3 decoding as you suspected, but it can be worked around quite easily if they’re permanently swapped at least.

When you mention “playing back directly from the device”, do you mean using some other program to play the PCM input?

What if you do a recording using Audacity or something similar?

Shados commented 1 year ago

Are the left and right channels permanently swapped or are they alternating during playback?

Permanently.

When you mention “playing back directly from the device”, do you mean using some other program to play the PCM input?

Pulseaudio loopback module from the input device to my output device.

What if you do a recording using Audacity or something similar?

Haven't tested this yet, will give it a go later, but would be very surprised if channels were flipped there...

jakemoroni commented 1 year ago

Interesting. I just checked again on my system and PCM has the correct mapping, but I did notice that I am not specifying a channel mapping for the PCM input (main.c:236) and PCM sink (pcm_sink.c:192), so it’s probably relying on the default mapping which is ‘Front Left, Front Right’ on my system.

Can you check your channel mappings while the program is running by running the following commands:

pactl list sources pactl list sinks

I’m curious to see if you have a different mapping. Even if not, I should probably specify a mapping anyway.

jakemoroni commented 1 year ago

After some testing on another system, I think this issue may be more complicated than initially thought.

I was able to observe the swapped channels (in PCM mode) on my newer system running Ubuntu 22.04. It was repeatable as well - every time I would run the application, they would be swapped, even after modifying the code to provide an explicit LEFT,RIGHT channel mapping on the source and sink.

However, if I ran "pavucontrol" before starting the application, then the channels were not swapped. This was also repeatable.

Why does starting Pulse Audio Volume Control have any effect on the channels being swapped? I have no idea...

Perhaps there is a bug in the pa_simple API?

Also, FWIW, AC3 never had this issue regardless of whether pavucontrol was running, but after reviewing the code (it's been a few years...), I think I know why. The 61937 state machine runs on a per 16 bit sample basis rather than a LEFT+RIGHT frame basis. So, swapping the left and right channels really has no effect as long as they still arrive in chronological order.

This also leads me to believe that the swap is occurring on the source side rather than the sink side.

I'll keep looking into this. It seems like maybe one single sample is being lost on the input, thus leaving the source forever out of sync. I'm not sure how though since pa_simple_read is supposed to read exactly the number of bytes specified.

jakemoroni commented 1 year ago

This issue has been fixed in commit 5b8c7bf. Reproduced, fixed, and tested on my setup using a MiniDSP USBStreamer.

It turns out that this was a bug in my program that would occur when there was a backlog of samples on the input, which would then cause the PCM sink buffer to fill up. Since the original ring buffer implementation would always leave one space in the buffer, this meant that it was possible for an odd number of samples to be queued, thus causing the left/right frame to become out of sync.

The fact that this did not occur when pavucontrol was running was likely because it kept the sources and sinks out of the SUSPENDED state, so when audio_async_loopback was started, there wasn't as much accumulated data waiting on the input.

Thanks for reporting this! Let me know if you encounter any more issues.