Re: [tim-janik/beast] Force alsa default device (#123)
Ebeast has PCM / MIDI device selection now. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/123#issuecomment-573305914___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Force alsa default device (#123)
Closed #123. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/123#event-2940547367___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Force alsa default device (#123)
> 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 maybe 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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/123#issuecomment-531332826___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Force alsa default device (#123)
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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/123#issuecomment-530792486___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Force alsa default device (#123)
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. -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/123#issuecomment-530171565___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
Re: [tim-janik/beast] Force alsa default device (#123)
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](https://askubuntu.com/questions/8425/how-to-temporarily-disable-pulseaudio/394872#394872)) 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) -- You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub: https://github.com/tim-janik/beast/pull/123#issuecomment-529153791___ beast mailing list beast@gnome.org https://mail.gnome.org/mailman/listinfo/beast
