Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Sound output choice passing uae-files? #1330

Closed
NoobieMaks opened this issue May 22, 2024 · 3 comments
Closed

Sound output choice passing uae-files? #1330

NoobieMaks opened this issue May 22, 2024 · 3 comments
Assignees
Labels

Comments

@NoobieMaks
Copy link

I'm using my own uae-files because the XML-file cannot meet all my requirements for controller shortcuts, display settings, usage of virtual keyboard and so on.
A part of this uae-file is o course also the used soundcard. So it's firm for each game (for the uae-files I only used headphone).
And that's my problem, I'm gaming on 2 different places, on the one with headphone jack and on the other with HDMI sound.
So I deleted manually all entries for the soundcard like this "amiberry.soundcard=" / "amiberry.soundcardname=" because I thought then amiberry will take the soundcard setting from amiberry.conf.
IMHO I thought this change of only one file, depending on which place I would like to play, would be my solution above all uae-files.
But I now I see when there is a uae-file existing the amiberry.conf will not be taken in consideration.
And uae-files without a definitive soundcard entry will take the soundcard in alphabetical order, so HDMI is first and Headphones second
and so I can't use Headphone as default over/above all. The empty uae-entry and the Headphone (default_soundcard=1) definiton in the amiberry.conf are useless.
Is there a chance to edit the soundcard beside the uae-files?
Perhaps an easy background change of the pull-down-menu order in the Sound -> Device menu would help. Can I edit this in a certain file?

@giantclambake
Copy link

Only because I've crossed this bridge before... and figured out the easiest work-around for me =)

..relative to Debian 12.5/amd64 with xfce4 WM with pulseaudio (PA) installed, current amiberry git preview branch

When you say 'headphones', we're actually talking about output 'jacks'. On the desktop, the host OS should take care of 'jack detection' when headphones are plugged in, and redirect output path from 'line out' to 'headphones' accordingly (I can choose between them if both jacks are plugged in, via the PA-volume-control utility). This is based on some daft logic that when a user plugs in headphones, then quite obviously they want to use those, and not the line out sound system.

When you say HDMI (DP+, other), we're actually talking about 'bridges'...hardware ICs. As such, these can/may run concurrently with the primary audio device, however jack detection still works on that device. Again, from the desktop, I can turn these devices on/off using the PA-volume-control utility. (I think 'port detection' also works here nowadays on the digital audio stuffs with PA).

So...seeing as I can futz with all of this stuff at the host OS level, I always figured it as beyond the purview of amiberry's control...(dunno how much is exposed in sdl_audio), so to create a "headphones only" config.uae you have to work with what you've got, which is significant ~ amiberry will always initialize with the host OS' definition of what is the primary (system default/index=0) audio device, unless otherwise overridden by config.uae ...of this, you can be sure.

Seeing as we don't have jack detection/selection, but do have SDL audio device selection ...we'll go with that... so I search ebay or such for "usb audio adapter" ...nice'n'cheap, choose your poison, some are better than others (add "interfaces" to the search string). As this is a USB hotplug device, it always enumerates as the 'secondary' sound device;

ex

As most all of these USB devices enumerate as hid-generic/hidraw class devices, naming of 'USB Audio Device Analog Stereo' is consistent across most all of these device (one config.uae fits all ;)

The resultant config.uae will contain;

amiberry.soundcard=1
amiberry.soundcardname=USB Audio Device Analog Stereo

//Fallback test: If amiberry loads a config.uae that defines soundcard settings for a soundcard device that doesn't exist //(USB audio adapter not plugged in), it uses the settings in amiberry.conf instead...result: Correct.

Thusly, you can create a config.uae file, that works with both the host OS' primary audio device setup, or exclusively with the USB audio (headphone) device if it's connected to the host system when amiberry is launched. You can't hotplug the device ; you have to Quit and restart amiberry for the added device to appear in the dropdown list. You can modify the user (me ;) procedure however, by plugging in the USB device the headphones are plugged into, instead of just plugging in the headphones to the primary sound device =)

I know it's not exactly what you're after here, but I thought I'd explain the workaround just in case it's useful example ;)

FWIW, the need for these meanderings was due to some (BIOS) behavior of a few USFF units with inbuilt speaker, that wouldn't turn off if headphones were jacked in (LFS build, alsa_lib only) ...you also had to feed it a few mod_params to promote the audio interface above DP+, and set the buffersize to avoid underruns (depends on which variant of intel q87 chipset is used) Disconnecting speaker soldered to board..too much time/effort, $5 USB solution.. these things bristle with USB ports on the front.

HTH

@midwan
Copy link
Collaborator

midwan commented May 23, 2024

Have you tried using the new "system default" option in the Sound panel? Does that use your system default audio output device?

@midwan midwan self-assigned this May 23, 2024
@NoobieMaks
Copy link
Author

NoobieMaks commented May 24, 2024

@midwan You are a genius, this checkbox is exactly what I needed, now amiberry can be configured like the other retroarch-emulators per system default sound option. Sorry, that I didn't see this new feature before.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants