Missing stereo sound in FS-UAE [Solved]

[yesplease]

Hi Frode,
played archon2 two players. There is an mighty figure in the game called wraith.
His ability is to become invisible. Only when he deals damage or when he got damage he becomes visible for a short moment. On my real amiga 1000, I can hear the opponents wraith coming from left to right and versa. The game developer did a nice job to use the stereo capabilities of the amiga. In FS-UAE however I can't hear in which direction the opponent player is moving his invisible wraith.

Really cool problem isn't it ???

Also with other figures when you shoot an arrow for example, you hear its flight route (left to right or right to left) on an real amiga 1000.

Is there an option to enable stereo in FS-UAE?

wish you the best.

[FrodeSolheim]

Hmm.. -the output is supposed to be stereo. But I checked and the output (on my computer) is effectively stereo downmixed to mono (and then duplicated to both speakers).

The Amiga emulation outputs stereo, and stereo buffers are sent to OpenAL. But the actual output is not stereo. I have verified that the issue occurs after the audio data is sent to OpenAL -because when I zeroed out the data for one of the stereo channels, I still got the other channel played on "both ears"...

I have not found any programming errors, and don't know why this does not work. I have tried various changes to the way OpenAL is initialized and used without success. Will keep trying of course, but all I can do right now is to confirm the problem.

[yesplease]

did you tested it on linux ? I tested it on OSX. Is it only on osx or is it a general platform independent openAL problem? Maybe if just one platform makes the trouble, we know which one is responsible for the cause. If all platforms making trouble maybe a general setting in openAL is missing?

[FrodeSolheim]

i actually tested it on Linux. Since these should be different OpenAL implementations, one might suspect I use OpenAL wrong. I haven't found anything useful in the OpenAL docs or by searching the web for what might be the problem. I have tried excpliticly hinting to OpenAL about the number of required stereo sources, etc, and verified that OpenAL understands that there are two audio channels in the queued buffer data...

[yesplease]

how does winuae does this ? do you use the same code ? From what I have read, they have the choice whether to output real stereo channels or mixed down ones in the winuae GUI ? Maybe fs uae on windows does the job ?

[FrodeSolheim]

Originally Posted by yesplease

how does winuae does this ? do you use the same code ? From what I have read, they have the choice whether to output real stereo channels or mixed down ones in the winuae GUI ? Maybe fs uae on windows does the job ?

No, this problem has nothing to do with WinUAE. Yes, much of the code is shared, but as I said above, I have verified that the problem appears when/after the sound is passed on to OpenAL, so if works correctly in the emulation layer...

[FrodeSolheim]

I suspect the problem may be related to the stereo buffers being attached to OpenAL sources, and that OpenAL downmixes the buffer to mono to be able for positioning in 3D space.

But the OpenAL specification indicates that this should not happen: "Buffers containing audio data with more than one channel will be played without 3D spatialization features – these formats are normally used for background music."

[TCD]

Maybe this is useful: http://www.opserver.de/ubb7/ubbthrea...&Number=386452 ?

[FrodeSolheim]

Originally Posted by TheCyberDruid

Maybe this is useful: http://www.opserver.de/ubb7/ubbthrea...&Number=386452 ?

Sorry, no

But I have actually made some progress. By checking the OpenAL soft sources I found out that the stereo buffers are not at all simply passed on the the left and right output channels, but are internally cross-mixed (at +30 and -30 degrees according to the source code). Still, in my ears, it sounds like the channels are completely mixed, but...

So the documentation is misleading at best. I don't at all agree that playing stereo buffers on OpenAL sources is good for background music, not when the channels are mixed like this..

I found this however:
http://opensource.creative.com/piper...ch/005879.html

Using this extension, where available, by setting AL_DIRECT_CHANNELS_SOFT on the source, the channels are directly mapped and stereo works as expected. At least on my Ubuntu 12.10 box, but this extension may not be available everywhere. Specifically, it is probably not available with the OS X OpenAL implementation.

But this should fix the issue for recent Linux distributions, and the Windows version at least. I will go on to see if there's anything to do for OS X as well...

[FrodeSolheim]

Actually, on my mac laptop, the OpenAL implementation works as expected with regards to stereo buffers

So while the OpenAL problem was real for at least the OpenAL soft version on my Ubuntu system, it may very well work fine on (all?) OS X systems (which have a different OpenAL implementation).

@yesplease Your issue may be much simpler. By default UAE *partially* mixes the stereo channels, and perhaps this is your only issue? FS-UAE does not have its own option for this, but you can pass on an UAE option to disable the partial mixing like this:

uae_sound_stereo_separation = 16

[FrodeSolheim]

Btw, I missed a multiplication by * 3 / 2 in the UAE source code, so max stereo separation is not 16, but actually 10:

uae_sound_stereo_separation = 10

(but for the record, 16 works as well, as the value is capped at maximum).

This means that the default stereo separation (7) is about 70%.

[yesplease]

Tried the setting, but it is totally mixed as before. Even plugged in a headphone so that i can hear the separation of sounds. Strange.

[FrodeSolheim]

Try the latest 2.1.19dev (just released), in case you have the OpenAL soft implementation on your system. If it does not help, please attach FS-UAE.log (or send to fs-uae@fengestad.no) as that will have some information about the OpenAL implementation.

[yesplease]

do you mean this:

openal device opened: Built-in Output
openal: created context
openal: made context current
openal version: 1.1
openal renderer: Software
openal vendor: Apple Computer Inc.
openal extensions: AL_EXT_OFFSET AL_EXT_LINEAR_DISTANCE AL_EXT_EXPONENT_DISTANCE AL_EXT_float32 AL_EXT_STATIC_BUFFER AL_EXT_SOURCE_NOTIFICATIONS
openal devices:
openal default device: Built-in Output
openal: number of stereo sources is 5
openal error 40962 (alGenSources)
openal error 40962 (alGenSources)


EDIT: it did not help, I sent you the complete log

EDIT2:
the following line is suspect "openal default device: Built-in Output"
maybe it is because mac mini has only mono internal speaker ?
But the sound definitly comes out of the earphones !!!

[yesplease]

Surprise !!

I put for the test case a standalone fs-uae.app with a self containing adf and configuration onto a usb-stick and started that on my old MacBook Pro same OSX version. And guess what, I could very clearly hear the stereo even without the "uae_sound_stereo_separation = 10" setting.

This very same adf containing standalone fs-uae.app, doesn't play stereo on the mac mini.

the minis logoutput "openal device opened: Built-in Output", makes me think that FSUAE chooses the default device that is the internal minis speaker which is only mono. OpenAl mixes the stereo to mono. And OSX later is routing this mono audio stream to the stereo headphone output, which I connected to stereo speakers. How about that theory Frode ? Does openal gives you a list of connected audio output devices from which you can choose from ? If so, can you make a built for further testing where you provide a setting where we can override the default audio device so that I can choose the headphone output? Also could you write those list of names of audio devices to the log.

[yesplease]

Now I am confused...

thought I was clever and connected the macmini with a hdmi-hdmi cable for testing purposes to the display (instead of a hdmi-dvi which doesn't transport audio) and set in osx hdmi as default audio out. Then connected my 2.1 stereo speaker system to headphone line out of the samsung display.

I got no stereo and I got these lines of log output


fs_emu_audio_init
openal device opened: HDMI
openal: created context
openal: made context current
openal version: 1.1
openal renderer: Software
openal vendor: Apple Computer Inc.
openal extensions: AL_EXT_OFFSET AL_EXT_LINEAR_DISTANCE AL_EXT_EXPONENT_DISTANCE AL_EXT_float32 AL_EXT_STATIC_BUFFER AL_EXT_SOURCE_NOTIFICATIONS
openal devices:
- HDMI
openal default device: HDMI
openal: number of stereo sources is 5

.... some lines later ...

initializing audio stream 0
frequency: 44100, buffers: 48 buffer size: 512 bytes
openal error 40962 (alGenSources)
initializing audio stream 1
frequency: 44100, buffers: 48 buffer size: 28224 bytes
openal error 40962 (alGenSources)


at least my ears have no mono defect ;-) as I can clearly distinguish what is stereo on the macbook. But that's of course not a HTPC. I am now not so sure with my theory which I stated above, must be something else wrong here in my setup, or is the display also a mono device ??? I doubt.

Frode, the good thing though is that you have now stereo !! At least one win ;-)

[FrodeSolheim]

No, I don't think the "built-in device is mono" theory is likely

But it is weird if it only works on one your OS X machines, especially if it's the same OS X version.

I assume there's no sound setting enabled on your system, where "dual mono" is forced somehow?

If the problem is not resolved in any other way, I might an SDL backend, which you can try instead of OpenAL. I am growing a bit weary about OpenAL (vague documentation, implementation-dependent behavior, etc).

[yesplease]

Oh my god you are so right, don't develop anything in the meantime I will report in a second into here, I just found a setting in the "osx->settings>accesibility for the invalids->audio->output stereo audio as mono" and it was set to TRUE

[yesplease]

Thank you so much Frode, my mac mini stereo problem is also solved ! I can hear the direction the wraith is moving !!!! Two Winners now ! ;-) !!!
http://eab.abime.net/images/smilies/bowdown.gif

Still don't know who set this silly setting to true ??? Maybe one of my kids...

[FrodeSolheim]

Hehe, yes, quite silly setting to have, and also a bit silly to not check that out first

But I'm very pleased you reported the "problem", because I did discover a real problem with OpenAL soft, which is used on most of the other platforms (and it is bundled with the Windows version of FS-UAE)