f2e-spec
f2e-spec copied to clipboard
Audio device configuration layout...
When PortAudio has many backends enabled (on MXE currently wmme,directx,wdmks,wasapi) or when there are many audio devices, the device configuration screen is almost unusable.
This is on my Windows desktop with just one sound device (& USB microphones):

I'm not sure how to make this better:
- We could just improve the presentation (make the screen scrollable)
- We could ignore specific backends (If one is better then the other) - Which ones?
- We could add another setting before the audio device selection: audio backend
- Something else?
We at least need to resolve the ambiguity in device naming, currently my list of devices looks like this:
audio/info: PortAudio devices:
#0 Microsoft Soundmapper - Input (2 in)
#1 FrontMic (Realtek High Definiti (2 in)
#2 Mikrofon (2- Wireless Mic #1220 (2 in)
#3 Microsoft Soundmapper - Output (2 out)
#4 Lautsprecher (Realtek High Defi (2 out)
#5 Realtek Digital Output (Realtek (2 out)
#6 S22C350-4 (NVIDIA High Definiti (2 out)
#7 Realtek HD Audio 2nd output (Re (2 out)
#8 Primärer Soundaufnahmetreiber (2 in)
#9 FrontMic (Realtek High Definition Audio) (2 in)
#10 Mikrofon (2- Wireless Mic #122038319 ) (2 in)
#11 Primärer Soundtreiber (2 out)
#12 Lautsprecher (Realtek High Definition Audio) (2 out)
#13 Realtek Digital Output (Realtek High Definition Audio) (2 out)
#14 S22C350-4 (NVIDIA High Definition Audio) (2 out)
#15 Realtek HD Audio 2nd output (Realtek High Definition Audio) (2 out)
#16 Realtek Digital Output (Realtek High Definition Audio) (2 out)
#17 Lautsprecher (Realtek High Definition Audio) (2 out)
#18 S22C350-4 (NVIDIA High Definition Audio) (2 out)
#19 Realtek HD Audio 2nd output (Realtek High Definition Audio) (2 out)
#20 Mikrofon (2- Wireless Mic #122038319 ) (2 in)
#21 FrontMic (Realtek High Definition Audio) (2 in)
#22 Kopfhörermikrofon (Bluetooth-Audio) (1 in)
#23 Headphones (Bluetooth-Audio) (2 out)
#24 Output (NVIDIA High Definition Audio) (2 out)
#25 Speakers (Realtek HD Audio output) (8 out)
#26 FrontMic (Realtek HD Audio Front Mic input) (2 in)
#27 Eingang (Realtek HD Audio Line input) (2 in)
#28 Mikrofon (Realtek HD Audio Mic input) (2 in)
#29 SPDIF Out (Realtek HDA SPDIF Out) (2 out)
#30 Stereomix (Realtek HD Audio Stereo input) (2 in)
#31 Headphones (Realtek HD Audio 2nd output) (2 out)
#32 Mikrofon (Wireless Mic #122038319) (2 in)
You can see that e.g. 10 and 20 are exactly identical, and indeed, when I select one of them in the UI, the other may be active when I enter the screen the next time...
quickest fix would be checking the list for double entries, but where to go from there?
another suggestions: It's possible to assign more then two players to one stereo input channel. There should be a limit.
The limit should be the max channels of the device being used..
Maybe a smaller font and a narrower left panel would be better?
just a pic with a webcam, 2 singstar wireless hubs and 2 other usb mics :D

Another one that would fit in here: connecting a behringer X32 only lists one device with 32 channels for recording, so basically you can only use one channel instead of all 32.
So let's see
- An audio device may have multiple channels, i bet they also have an option to give us how much channel it has
- We could check for double entries and just distinct that list, that'd help alot yet not fix the problem.
TODO:
- [x] Set max limit equal to the amount of input channels (for mics)
- [x] Check if someone tries to break it and add more than max limit. currently it resets the view completely
- [x] Don't list disabled devices (i don't know if we do though) since they won't
open - [x] Check if a listed audio device is disabled / not connected and don't show it in this case
- [x] Check if a listed audio device is disabled / not connected and don't show it in this case
@basisbit added it to the list thanks 👍
The thing I did the other day for text rendering makes it a tad more bearable because it ensures each line is completely inside the screen (although we'll need to stretch that gray background a bit).
Besides that, I really think a good short-term solution is what I suggested before : settle for a single backend at a time.(For windows probably wmme or directx/wasapi) but retain the ability to change it, via command-line.
For the long-term, it might be worth at least considering a move to another library. I posted this on discord the other day and while it has some issues, I think it wouldn't be a terrible idea to monitor its progress and eventually perhaps play with it on another branch. http://libsound.io
There's a bit at the bottom with links to pages comparing it to other common libs like portaudio and sdl2
please bear in mind that https://github.com/andrewrk/libsoundio/wiki/libsoundio-vs-SDL2 is outdated now that SDL2 supports audio input devices, including plug&pray events,... libsound would be a new additional dependency. Additionally, libsound does not support older Windows / Linux / OS X.
Well, eventually if we ended up using it, it would replace portaudio so it would leave us in the same place regarding dependencies.
Re: Older windows... We're talking about pre-windows 7. I don't really think we should be concerned about that. Don't know how far back is the Linux support though. As for OSX, we currently support 10.9+ only.
I'm just raising the issue because I think it merits some discussion as a long-term thing.
Linux goes from trusty (Ubuntu 14.04 LTS) which is released in 2013 Ubuntu 14.04.5 LTS which the buildserver uses has an end of life date of april 2019.
Windows XP had reached End of support at April 8th, 2014 Windows Vista had reach end of support at 11 April 2017
i think its best to investigate sdl2's sound support and possibly sdl2_mixer. this would cut down another dependancy
Op 28 jun. 2017 19:14 schreef "Arjan Spieard" [email protected]:
Linux goes from trusty (Ubuntu 14.04 LTS) which is released in 2013 Ubuntu 14.04.5 LTS which the buildserver uses has end of life date april 2019.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/performous/performous/issues/160#issuecomment-311726970, or mute the thread https://github.com/notifications/unsubscribe-auth/ACqjW6URnJOKehQceitUX584Bo5-eHsjks5sIonpgaJpZM4F7MwO .
This is what the audio device screen looks on macOS 10.13.6 with a Behringer X32 Compact (shown as X-USB) connected. When setting microphones to the X-USB they get mapped to channels 1-8 on that interface. (Card OUT 1-8 on the X32.)
This is Performous 1.1-4-g98c7537 (from the official download for macOS).

@MacLemon please create a new issue for your problem instead of posting this in a not related two years old issue. Thanks.
indeed. btw, the solution is to use jack audio connection kit (software) to re-route the mic channels.
2019年9月29日(日) 7:29 basisbit [email protected]:
@MacLemon https://github.com/MacLemon please create a new issue for your problem instead of posting this in a not related two years old issue. Thanks.
— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/performous/performous/issues/160?email_source=notifications&email_token=AAVKGWZ4SO2NQSW4GR4QNXLQMA4LFA5CNFSM4BPMZQHKYY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD73IXFQ#issuecomment-536251286, or mute the thread https://github.com/notifications/unsubscribe-auth/AAVKGW4LTZFLODSC3I5Z2I3QMA4LFANCNFSM4BPMZQHA .
Sorry, the issue was old but open and I could contribute a screenshot to illustrate how other interfaces show up without splitting their channels into ginormous lists.
I've removed the part which was interpreted as a support request, which is wasn't meant to be. There indeed seems to be a channel matching problem in Performous which I'll open a separate issue for (and known workaround for macOS).
I think this issue is already solved by now since there has been quite a rework on the audio system. Anyone who can verify?
you might want to use the checklist here in the issue to see what still is left to do 👍
I think this issue is already solved by now since there has been quite a rework on the audio system. Anyone who can verify?
Yes, the backend selection system I implemented should have taken care of it. We might still want to take a look at SDL2 sound though, maybe?
I think all of the items in the list are already done in current master. Tested it with latest windows build and it shows exactly what i want it to show.

Can linux/osx people confirm this too?