Created attachment 169029 [details] Patch adding ALSA alises to the available devices. When using ALSA with FreeBSD, the direct snd_device instances are not available, only plugin devices and "default". For programs which use QAudio, this means there are *no* devices enumerated using QAudio::availableDevices(). The attached patch adds the aliases to the available device list.
Created attachment 169043 [details] Patch adding ALSA alises to the available devices. Update with unified diff.
Does that code also work on Linux? It looks like something that should be reviewed upstream before we start shipping on FreeBSD.
(In reply to Raphael Kubo da Costa from comment #2) It should, but I'm not in a position to test it.
OK. In any case, I think the best course of action is to submit it upstream via Gerrit (see https://wiki.qt.io/Qt_Contribution_Guidelines and https://wiki.qt.io/Gerrit_Introduction) so that the Qt folks can take a look at this and also make check if it works fine on Linux.
Submitted to upstream Gerrit... https://codereview.qt-project.org/155883
Upstream patch greatly simplified...
ports r414376 may help enumerating pcm devices. "default" is still recommended due to implicit sample format conversion. $ aplay -L null Discard all samples (playback) or generate zero samples (capture) pulse PulseAudio Sound Server oss Open Sound System
Created attachment 171369 [details] Test application Here is a test-application showing what QAudioDeviceInfo::availableDevices() shows. It just prints out the names of the devices that are found. Compile it with: c++ -o audiolist -fPIC -std=c++11 -I /usr/local/include/qt5 -L /usr/local/lib/ -lQt5Multimedia -lQt5Core audiolist.cpp (once qt5-multimedia is installed)
What is the problem that is being solved here, and what role does ALSA (aplay) have here? For instance, I have a 10-STABLE machine here, with Qt 5.5.1 installed, and alsa-utils-1.1.1. This is the output of aplay -L: null Discard all samples (playback) or generate zero samples (capture) oss Open Sound System This is the output of my test application: AUDIO "oss" AUDIO "default" With the patch applied, this is the output: AUDIO "oss" AUDIO "oss" AUDIO "default" Yes, that's an extra line of "oss". This does not seem to be an improvement. My /dev/sndstat is this: pcm0: <Realtek (0x0900) (Rear Analog 7.1/2.0)> (play/rec) default pcm1: <Realtek (0x0900) (Front Analog)> (play/rec) pcm2: <Realtek (0x0900) (Onboard Digital)> (play) pcm3: <Intel (0x2809) (HDMI/DP 8ch)> (play) Is there some configuration that I would need to do to find these devices either with aplay or with the patched Qt5Multimedia?
(In reply to groot from comment #9) > My /dev/sndstat is this: > pcm0: <Realtek (0x0900) (Rear Analog 7.1/2.0)> (play/rec) default > pcm1: <Realtek (0x0900) (Front Analog)> (play/rec) > pcm2: <Realtek (0x0900) (Onboard Digital)> (play) > pcm3: <Intel (0x2809) (HDMI/DP 8ch)> (play) > > Is there some configuration that I would need to do to find these devices > either with aplay or with the patched Qt5Multimedia? Only natively[1], better fall back to "default" PCM. 4Front OSS on Linux (e.g. oss4-dkms on Debian) likely has similar issue. $ aplay -l aplay: device_list:273: no soundcards found... In-kernel ALSA (i.e. hw:X,Y) exists only on Linux, other systems are limited to userland. OSS from alsa-plugins lacks support for MIDI sequencer, selecting/enumerating devices and probably more. Unlike OpenBSD (sndio) we don't have anyone actively working on adding OSSv4 support in ports/ tree. [1] http://manuals.opensound.com/developer/SNDCTL_CARDINFO.html (see example)
(In reply to groot from comment #9) > Is there some configuration that I would need to do to find these devices > either with aplay or with the patched Qt5Multimedia? You can create aliases in your ~/.asoundrc... here's mine: pcm.envy24 { type oss device /dev/dsp0 } pcm.mb_rear { type oss device /dev/dsp4 } pcm.mb_front { type oss device /dev/dsp5 } pcm.ts940 { type oss device /dev/dsp6 } ctl.envy24 { type oss device /dev/mixer0 } ctl.mb_rear { type oss device /dev/mixer4 } ctl.mb_front { type oss device /dev/mixer5 } ctl.ts940 { type oss device /dev/mixer6 }
Using the test application and the current upstream patch, I get this: AUDIO "default" AUDIO "envy24" AUDIO "mb_rear" AUDIO "mb_front" AUDIO "ts940"
Created attachment 171561 [details] Patch as submitted upstream Adding the currently submitted upstream patch.
hi! Is it possible to get this committed to our ports repository until the upstream issues are resolved? Otherwise right now we can't easily use multiple sound devices in QT multimedia applications w/ multiple sound cards, like wsjtx. Thanks! -adrian
Any news here?
Hi, this has been lagging for too long. I'd like to commit this in 48 hours to unblock things so we can at least get SOME useful behaviour on qt5-multimedia until we get a more comprehensive upstream support plan.
See review; patch run through makepatch, and dropped one hunk that is no longer needed.
A commit references this bug: Author: adridg Date: Sat Jan 20 12:45:13 UTC 2018 New revision: 459518 URL: https://svnweb.freebsd.org/changeset/ports/459518 Log: Allow ALSA aliases in the Qt5 sound devices list. Patch by Stephen Hurd, seems to be ignored upstream. The new patch describes what it does and why it is needed. PR: 208570 Submitted by: Stephen Hurd Reported by: Stephen Hurd Approved by: tcberner (mentor) Differential Revision: https://reviews.freebsd.org/D13992 Changes: head/multimedia/qt5-multimedia/Makefile head/multimedia/qt5-multimedia/files/patch-src_plugins_alsa_qalsaaudiodeviceinfo.cpp
Applied to current Qt 5.9.3 port. Thanks Adrian for prodding.