Force alsa default device

[swesterfeld]

This is a fix for #119 - and finally should make beast work out of the box for users which have pulseaudio as default device (for instance together with jack/bridging). For me at least this fixes "make run".

In order to force using the default device if available, pcm drivers can return a string which device is the default device.

[tim-janik]

This patch causes a regression on my system (Ubuntu 18.04 with pulseaudio) when opening media/Demos/stereo-through.bse. Without the patch, I can play this:

BSE_DEBUG=snd pasuspender -- out/beast-gtk/beast-0.15.0 out/media/Demos/stereo-through.bse 
snd: bse_device_open: BsePcmDeviceALSA: default: Bse.Error.DEVICES_MISMATCH
snd: bse_device_open: BsePcmDeviceALSA: null: Bse.Error.DEVICE_BUFFER
snd: bse_device_open: BsePcmDeviceALSA: pulse: Bse.Error.DEVICES_MISMATCH
snd: bse_device_open: BsePcmDeviceALSA: sysdefault:CARD=PCH: Bse.Error.DEVICES_MISMATCH
snd: bse_device_open: BsePcmDeviceALSA: front:CARD=PCH,DEV=0: Bse.Error.NONE

FYI, without pasuspend, opening 'front' gives Bse.Error.FILE_BUSY. So fixing 'default' as the only ALSA device to open doesn't work for opening in Duplex mode with pasuspend. Note that even without pulseaudio (killing pulseaudio) running, I'm getting:

   >        default:CARD=PCH - HDA Intel PCH, ALC298 Analog Default Audio Device
   >        front:CARD=PCH,DEV=0 - HDA Intel PCH, ALC298 Analog Front speakers
snd: bse_device_open: BsePcmDeviceALSA: default:CARD=PCH: Bse.Error.DEVICES_MISMATCH
snd: bse_device_open: BsePcmDeviceALSA: front:CARD=PCH,DEV=0: Bse.Error.NONE

So I'm not sure what ALSA picks as 'default' (without pulse), but it doesn't have matching mixfreq/fragment sizes which are needed for duplex mode. (BSE_DEBUG=snd is supported by recent master)

[tim-janik]

A bit of evaluation on Ubuntu 18.04:

• Bitwig defaults to opening JACK and issues a warning if that fails. It provides JACK, ALSA and PulseAudio drivers. For the ALSA driver, the user has to select one of the available ALSA hardware drivers (hw:*).
• Reaper defaults to opening JACK and issues a warning if that fails. It does allow the user to manually select ALSA, a dummy driver or PulseAudio. Oddly enough, with ALSA it only recognizes the first hardware device. Reaper allows the project to render with a different sample rate than used by the audio device.
• Renoise tries to open ALSA's first hw device (hw:0,0), its ALSA driver allows manual selection of all ALSA hardware devices (hw:*). If ALSA hw:0 doesn't work, it tries to fallback to its second driver JACK, if that doesn't work it gives up.
• Firefox and Google-chrome simply use Pulseaudio out of the box and support Duplex operation. Via Pulseaudio, it's possible to change between Headphone and Laptop mic/speakers while a call is ongoing. Since they can also mix-in remote audio, they must have some kind of drift-compensation.

Insisting on using a JACK driver when Jackd is not running or not even installed on a system is simply user-unfriendly. Renoise knows better and can play out of the box via ALSA, but if that doesn't work, it's worse of than any of the other programs, because it fails to recognize/use PulseAudio.

The browsers are a magnitude more user friendly than any of the DAWs, they support PulseAudio out of the box, try to minimize latency for interactive calls, work in Duplex mode out of the box and compensate drift automatically.

For Beast, we should simply work as well and as user-friendly as the browsers by picking PuleAudio by default, trying JACK only if Jackd is running and falling back to the first ALSA hw device if it is not busy. That way, power users can manually assign JACK as the default driver and for everyone else, things will work out of the box. But we need some kind of drift compensation when we use PulseAudio in Duplex mode.

[swesterfeld]

Ok, first of all, I no longer think that changing the auto-detect order for devices can solve our problem. As I understand it for, you

• have a duplex (non-default) device you want beast to use
• have a alsa non-duplex default device that you don't want beast to use

On the other hand, I

• have a duplex device I don't want beast to use
• have a alsa non-duplex default device (pulse) I want beast to use

So it seems to me that this cannot be automatically be resolved (so the patch here cannot be improved to a state where it works out of the box for both of us).

So we need explicit driver selection in the future. So eventually we will need .bserc to have an entry for setting the audio driver. I can understand that adapting beast-gtk may not be what we want to do, since it makes not much sense to invest time in legacy ui code. I can also understand that adapting ebeast may not yet be what we want to do, because it may need more time to develop ebeast until it is time to add a configuration dialog. But that will happen eventually.

So I suggest adding a .bserc option for selecting the driver, so that at least I can test ebeast, and in the future the configuration dialog can make this meaningful for average users.

And we need not necessarily solve the drift compensation issue before we even have a usable ebeast ui that would benefit from it.

[swesterfeld]

For Beast, we should simply work as well and as user-friendly as the browsers by picking PuleAudio by default, trying JACK only if Jackd is running and falling back to the first ALSA hw device if it is not busy.

In the situation where PulseAudio and JACK are available, I think we should choose JACK. It is highly unlikely that jackd is running by accident. The user made it run. So the user wants to have low latency communication between all his pro-audio applications. Note that Bitwig doesn't support inputs if you use PulseAudio. I guess they also didn't want to implement drift compensation.

[tim-janik]

Ok, first of all, I no longer think that changing the auto-detect order for devices can solve our problem.

I think we can get very close to 0-config for most users by doing this:

1) Pick Jack driver if and only if Jackd is running. 2) Pick Pulseaudio if it is available, note that this does not support snd_pcm_link and needs some drift compensation. 3) Pick the first ALSA HW device, that should support snd_pcm_link. 4) Otherwise leave it to the user via the preferences dialog.

The only thing I'm not perfectly sure about is if a linked HW device (3) is better than Pulseaudio with drift compensation (2). From a quality standpoint, (3) would be clearly better. But imagine a user has Pulseaudio hooked up to his second ALSA device, e.g. USB headphones. If Beast prefers the first ALSA device over Pulseaudio, it can link Duplex channels, but may blast onto laptop speakers unintentionally or may be utterly silent if hw:0,0 is a desktops onboard sound with an unconnected stereo jack.

So we need explicit driver selection in the future. So eventually we will need .bserc to have an entry for setting the audio driver. I can understand that adapting beast-gtk may not be what we want to do, since it makes not much sense to invest time in legacy ui code.

I've almost thrown away the entire preferences code in beast-gtk yesterday, because it depends on the Visitor code which doesn't compile due to a g++-8 bug. I did find a workaround in the end though. But don't count on that code to stay around much longer.

I can also understand that adapting ebeast may not yet be what we want to do, because it may need more time to develop ebeast until it is time to add a configuration dialog. But that will happen eventually.

Ebeast has had a preferences dialog since mid-May.

We just need to add PCM device selection to it.

[tim-janik]

Ebeast has PCM / MIDI device selection now.