Linux FAQs

[ungleichklang (LXNDR TYLR)]

@rhowaldt

How does it compare to Openbox?

On my machine OpenBox was equal to LXDE, but I still prefer XFCE.
I think it’s just a question of choosing your favorite WM among those mentioned.

And for my taste OpenBox is too … nacked?? If I have to extend it with LXpanel I can stick to LXDE …

[rhowaldt]

@ungleichklang

On my machine OpenBox was equal to LXDE, but I still prefer XFCE.
I think it’s just a question of choosing your favorite WM among those mentioned.

And for my taste OpenBox is too … nacked?? If I have to extend it with LXpanel I can stick to LXDE …

yeah i was asking because i wondered how it compared to the others. i went for #! linux with openbox and am loving it, but i never tried the others. i use openbox (an #!) because it is fast, small and lightweight, so should be good for making music. i also asked because i did not find Openbox buggy, as you said LXDE was. i’m sure its a matter of taste though. i use tint2 instead of lxpanel, works pretty smooth.

[bluszcz]

When I was using 100% Linux I was using dwm.suckless.org. - mininalistic nad works nice with renoisee

@rhowaldt

How does it compare to Openbox?

XFCE is bloated, but maybe not so bloated like the other ones…

[abique]

Could renoise use ALSA, but in shared mode?

[vvoois (vV)]

@abique

Could renoise use ALSA, but in shared mode?

Alsa cannot be used in shared mode, you need layers above it that allow sharing of audio resources.

[Moxon (Nicolai)]

@vV

Alsa cannot be used in shared mode, you need layers above it that allow sharing of audio resources.

One such layer can be the JACK infrastructure.

I use it a lot and can keep Renoise, Youtube and my music player happy at the same time.

[abique]

@Moxon

One such layer can be the JACK infrastructure.

I use it a lot and can keep Renoise, Youtube and my music player happy at the same time.

Jack and youtube? How?
Anyway why couldn’t renoise just use ALSA in a non-exclusive way?

[vvoois (vV)]

@abique

Jack and youtube? How?
Anyway why couldn’t renoise just use ALSA in a non-exclusive way?

No program can use ALSA in shared mode. I believe there was a trick using OSS compatability layer but i think this no longer works in the newest Linux distributions. But frankly Alsa gains exclusive access to the sound-device that you are using and only allows one program to access Alsa.
Soundbridges like Jack or PulseAudio use Alsa and on their term, allow multiple programs to use their sound architecture.
PulseAudio is the least time-efficient soundbridge, yet the majority of applications nowadays use PulseAudio.
When Renoise was ported to Linux, PulseAudio didn’t existed yet hence Renoise supports either Alsa or Jack.

I’m not familiar if Pulseaudio could be configured to use Jack as its audiosource instead of Alsa, but i suspect that if you can, your problem is solved.

[abique]

@vV

No program can use ALSA in shared mode. I believe there was a trick using OSS compatability layer but i think this no longer works in the newest Linux distributions. But frankly Alsa gains exclusive access to the sound-device that you are using and only allows one program to access Alsa.

I bet that you’re wrong man
Otherwise how can I play youtube with flash + smplayer + clementine + … at the same time?

Without any userland sound daemon.

[vvoois (vV)]

@abique

I bet that you’re wrong man

It looks like you are right about me being wrong, i based my interpretations on found forum and knowledgebase questions where developers come up with questions about ALSA’s exclusive claiming of audio devices and they get simply answered that Alsa doesn’t share the sound-device. But i think i misinterpreted the idea where developers wanted to claim the audio device directly rather than use Alsa at all.

@abique

Otherwise how can I play youtube with flash + smplayer + clementine + … at the same time?

Without any userland sound daemon.

I doubt they don’t use an audio deamon, http://tuxradar.com/…audio-explained :

If you’re thinking that things are going to get easier with ALSA safely behind us, you’re sadly mistaken. ALSA covers most of the nuts and bolts of getting audio into and out of your machine, but you must navigate another layer of complexity. This is the domain of PulseAudio - an attempt to bridge the gap between hardware and software capabilities, local and remote machines, and the contents of audio streams. It does for networked audio what ALSA does for multiple soundcards, and has become something of a standard across many Linux distros because of its flexibility.

As with ALSA, this flexibility brings complexity, but the problem is compounded by PulseAudio because it’s more user-facing. This means normal users are more likely to get tangled in its web. Most distros keep its configuration at arm’s length; with the latest release of Ubuntu, for example, you might not even notice that PulseAudio is installed. If you click on the mixer applet to adjust your soundcard’s audio level, you get the ALSA panel, but what you’re really seeing is ALSA going to PulseAudio, then back to ALSA - a virtual device.

At first glance, PulseAudio doesn’t appear to add anything new to Linux audio, which is why it faces so much hostility. It doesn’t simplify what we have already or make audio more robust, but it does add several important features. It’s also the catch-all layer for Linux audio applications, regardless of their individual capabilities or the specification of your hardware.

This snippet does explain Alsa should be capable to share audio among multiple applications (because OSS was exactly lacking that)

ALSA is responsible for translating your audio hardware’s capabilities into a software API that the rest of your system uses to manipulate sound. It was designed to tackle many of the shortcomings of OSS (and most other sound drivers at the time), the most notable of which was that only one application could access the hardware at a time. This is why a software component in ALSA needs to manages audio requests and understand your hardware’s capabilities.

It does also explains this about the Alsa driver:

But it’s also far more ambitious than a normal kernel driver; it can mix, provide compatibility with other layers, create an API for programmers and work at such a low and stable latency that it can compete with the ASIO and CoreAudio equivalents on the Windows and OS X platforms.

I suspect for the latter, exclusive mode is required as Renoise aims for low latency. I’m not sure if adding an Alsa shared mode is easily done, but performance wise this is really not a good idea at all, it beats the purpose of serious music production.
Besides, once Renoise would run in shared mode, i am not sure either if Alsa can be claimed strictly again if other applications already have access to Alsa.

[abique]

@vV

I doubt they don’t use an audio deamon.

I suspect for the latter, exclusive mode is required as Renoise aims for low latency. I’m not sure if adding an Alsa shared mode is easily done, but performance wise this is really not a good idea at all, it beats the purpose of serious music production.
Besides, once Renoise would run in shared mode, i am not sure either if Alsa can be claimed strictly again if other applications already have access to Alsa.

1. You can select them to use alsa backend and not jack or pulseaudio, I know that I have no user land sound server.

2. I don’t understand how jack being a user land sound server could provide a better “real time” mixing than ALSA being a kernel land sound server. But on the other hand I can understand that exclusive mode can improve performances, but here we need numbers, and without them it means nothing. I think we have to try how it goes with ALSA + shared mode, eventually add both ALSA exclusive and ALSA shared mode avalaible.

I used wine + reaper using the new windows sound driver which is marked experimental on reaper, in shared mode. I had no issue at all, and excellent settings: 5ms at 96khz.

[vvoois (vV)]

@abique

2. I don’t understand how jack being a user land sound server could provide a better “real time” mixing than ALSA being a kernel land sound server. But on the other hand I can understand that exclusive mode can improve performances, but here we need numbers, and without them it means nothing.

I wasn’t mentioning Jack in that piece you quoted anywhere so this means i wasn’t speaking about Jack regarding low latency and exclusivity, that was still about Alsa.
Jack offers audio and midi patching between audio applications, which is usually a warm welcome if you want to route the audio and midi of multiple audio applications among each other.

[abique]

@vV

I wasn’t mentioning Jack in that piece you quoted anywhere so this means i wasn’t speaking about Jack regarding low latency and exclusivity, that was still about Alsa.

Yeah I’m sorry I should not have introduced Jack here. I did it because a lot of people recommend it so I used it as an argument to say that ALSA in shared mode should not be worse than Jack for performances.

[pussi]

@abique

Jack and youtube? How?

what I do is start jackd on system startup and route all alsa audio to jack with alsa’s jack plugin

or if you’re using pulseaudio you can install pulseaudio jack sink. There should be no configuration required iirc, pulseaudio should switch to jack sink automatically when you start jack.

to get youtube videos play with this setup, you still need to route alsa applications to pulseaudio, which is as simple as installing alsa-plugins and using this as alsarc:

pcm.pulse {  
 type pulse  
}  
ctl.pulse {  
 type pulse  
}  
pcm.!default {  
 type pulse  
}  
ctl.!default {  
 type pulse  
}