What features/changes would you like to see in future Slackware?

TobiSGD · 06-10-2015, 09:37 AM

Quote:

Originally Posted by genss

thats the only thing a sound server is useful for, he knows that and is just trolling

If having a demand for something is now counting as trolling than this thread should be closed because it seems to be full of trolls.

dugan · 06-10-2015, 09:43 AM

The actual ways to switch between two sound cards when using ALSA do not involve "DMix", and they're not better than using Pulseaudio.

http://alsa.opensrc.org/MultipleCards

genss · 06-10-2015, 09:43 AM

Quote:

Originally Posted by TobiSGD

If having a demand for something is now counting as trolling than this thread should be closed because it seems to be full of trolls.

dont
just dont

if you need that niece thing, you can easily install PA from SBo
its even better since PA seems to do some cache dependent things when compiling,
so if it's compiled on a dedicated compile cpu with a ton of cache it will run slower on a cpu with less cache
(PA is bad with cache anyway)

genss · 06-10-2015, 09:47 AM

Quote:

Originally Posted by dugan

The actual ways to switch between two sound cards when using ALSA do not involve "DMix", and they're not better than using Pulseaudio.

http://alsa.opensrc.org/MultipleCards

ls .asoundrc*
.asoundrc_card .asoundrc_direct .asoundrc_jack .asoundrc_pulse

you can make a script if you want

and it is better then using PA, performance/battery and latency wise

dugan · 06-10-2015, 09:59 AM

Quote:

Originally Posted by genss

ls .asoundrc*
.asoundrc_card .asoundrc_direct .asoundrc_jack .asoundrc_pulse

Not a bad idea.

ReaperX7 · 06-10-2015, 10:11 AM

Quote:

Originally Posted by dugan

Hey ReaperX. I'm not understanding how you managed to set up "DMix" for multiple sound devices either. Could you please post more precise instructions? I didn't see them at your ArchWiki link.

I'm not personally at the "I'm all for Pulseaudio to be added" stage yet, but I do plan start using and evaluating it soon. That I'll want to easily to switch between my onboard and USB sound cards is a big reason.

I pretty much copied a template from here and edited it up a bit, I references the archwiki but I used a few extra pages. Yes, using Pulse would make it easier though, but it's not technically required.:

http://www.alsa-project.org/main/index.php/Asoundrc

To be honest JACK will make it easier, but to each their own.

I borrowed this for my own system and use it, it works.

Code:

pcm.headset {
    type hw
    card 1
}

ctl.headset {
    type hw
    card 1
}

pcm.pci {
    type hw
    card 0
}

ctl.pci {
    type hw
    card 0
}

pcm.onboard {
    type hw
    card 2
}

ctl.onboard {
    type hw
    card 2
}

pcm.pciDmixed {
   type dmix
   ipc_key 1024
   ipc_key_add_uid false
   ipc_perm 0666
   slave {
       pcm "pci"
       period_time 0
       period_size 2048
       channels 4
       rate 192000
    }
    bindings {
       0 0
       1 1
       2 2
    }
}

pcm.onboardDmixed {
   type dmix
   ipc_key 2048
   ipc_key_add_uid false
   ipc_perm 0666
   slave {
       pcm "onboard"
       period_time 0
       period_size 2048
       channels 2
       rate 96000
    }
    bindings {
       0 0
       1 1
    }
}

pcm.both {
    type route;
    slave.pcm {
        type multi;
        slaves.a.pcm "onboardDmixed";
        slaves.b.pcm "pciDmixed";
        slaves.a.channels 2;
        slaves.b.channels 4;
        bindings.0.slave a;
        bindings.0.channel 0;
        bindings.1.slave a;
        bindings.1.channel 1;
      
        bindings.2.slave b;
        bindings.2.channel 0;
        bindings.3.slave b;
        bindings.3.channel 1;
        bindings.4.slave b;
        bindings.4.channel 2;
        bindings.5.slave b;
        bindings.5.channel 3;
    }
  
    ttable.0.0 1;
    ttable.1.1 1;
  
    ttable.0.2 1;
    ttable.1.3 1;
    ttable.2.4 1;
    ttable.3.5 1;
}

pcm.!default {
        type plug
        slave {
                pcm both
        }
}

ctl.!default {
        type hw
        card 0
}

Kinda found on Slack4Dummies site and edited it to suit my needs.

http://slack4dummies.blogspot.com/20...ple-sound.html

This is my /etc/modprobe.d/alsa.conf file

Code:

# ALSA portion
       alias char-major-116 snd
       alias snd-card-0 snd-virtuoso
       alias snd-card-1 snd-usb-audio
       options snd-usb-audio index=-2
       
# OSS/Free portion
       alias char-major-14 soundcore
       alias sound-slot-0 snd-card-0
       alias sound-slot-1 snd-card-1
       
# card 1
       alias sound-service-0-0 snd-mixer-oss
       alias sound-service-0-1 snd-seq-oss
       alias sound-service-0-3 snd-pcm-oss
       alias sound-service-0-8 snd-seq-oss
       alias sound-service-0-12 snd-pcm-oss

# card 2
       alias sound-service-1-0 snd-mixer-oss
       alias sound-service-1-3 snd-pcm-oss
       alias sound-service-1-12 snd-pcm-oss

TobiSGD · 06-10-2015, 10:41 AM

Quote:

Originally Posted by genss

dont
just dont

if you need that niece thing, you can easily install PA from SBo

So consensus is: Never ask for something being included that is already on SBo? Didn't know that.

Didier Spaier · 06-10-2015, 11:04 AM

Quote:

Originally Posted by TobiSGD

So consensus is: Never ask for something being included that is already on SBo? Didn't know that.

I am not aware of such a consensus, but there are pros and cons:

Having the stuff on SBo _can_ be reassuring that it works and decrease further packaging work.
On the other hand, one _could_ ask: it's already on SBo, is it essential to include it in Slackware, that can't ship everything?

My guess is that ease of maintenance, security, and value added by the integration in Slackware (does the distribution as a whole benefit of adding that stuff?) are among the concerns, but of course that's just a guess.

genss · 06-10-2015, 11:06 AM

Quote:

Originally Posted by TobiSGD

So consensus is: Never ask for something being included that is already on SBo? Didn't know that.

no,
the "consensus" (there isn't any in a dictatorship) is something like "if only one of 1000 users actually needs it, s/he can find it on SBo"
its not "everybody has to use this shit thing because I need/want it"

i told you don't
im not in the mood for self-centered idiots today

I asked here (nicely) for openbox
it didnt get added
i didnt turn up a shitstorm

ReaperX7 · 06-10-2015, 11:37 AM

The problem of including stuff from SBo back into the main distribution is that:

1. It adds to the disk size, as if it's not big enough and we are edging closer to the DVD+R capacity limit. Small stuff is fine, but larger stuff can be bad. I seriously doubt we want Slackware to push a two DVD set, or worse, Dual-Layer DVD, which are a pain in the ass to burn correctly, and not everyone has Blu-Ray Burners.

2. Not everyone will use or need it, even if it rounds out the distribution to cater to desktops, laptops, and servers alike. Is it sane for the system to have it?

3. Unless it's a mission critical library for a dependency resolution, chances are it may never make it out of SBo into Slackware itself.

4. It still has to make it past Patrick. 1, 2, and 3 actually sum up the answer Patrick usually will give, and unless all three, in general example, can get a yes, it's always a unilateral no, and even then it's still on a whim.

While I'd love to see OpenRC get folded into Slackware, I know it probably won't, even though it can meet everything on the checklist, and doesn't replace a lot from sysvinit, but at least it can be found on SBo.

ReaperX7 · 06-10-2015, 12:00 PM

Separate post but whatever...

I updated upower-0.9.23 to upower-0.99.3 on my system and rebuilt xfce4-power-manager-1.4.4, both run as intended, so these could effectively be upgraded once rebuilt.

Readouts from upower-0.99.3

Code:

bash-4.3# upower -v && upower -d
UPower client version 0.99.3
UPower daemon version 0.99.3
Device: /org/freedesktop/UPower/devices/DisplayDevice
  power supply:         no
  updated:              Wed 10 Jun 2015 09:45:50 AM PDT (675 seconds ago)
  has history:          no
  has statistics:       no
  unknown
    warning-level:       none
    icon-name:          ''

Daemon:
  daemon-version:  0.99.3
  on-battery:      no
  lid-is-closed:   no
  lid-is-present:  no
  critical-action: PowerOff

Readouts from xfce4-power-manager-1.4.4 (rebuilt against upower-0.99.3)

Code:

bash-4.3# xfce4-power-manager -V && xfce4-power-manager --dump

Xfce Power Manager 1.4.4

Part of the Xfce Goodies Project
http://goodies.xfce.org

Licensed under the GNU GPL.

---------------------------------------------------
       Xfce power manager version 1.4.4
With policykit support
With network manager support
---------------------------------------------------
Can suspend: True
Can hibernate: True
Authorized to suspend: True
Authorized to hibernate: True
Authorized to shutdown: True
Has battery: False
Has brightness panel: False
Has power button: True
Has hibernate button: True
Has sleep button: True
Has LID: False

I am however using ConsoleKit2 and LoginKit-0.1 from my repository, so anyone else using ConsoleKit-0.4.2 might want to test this.

TobiSGD · 06-10-2015, 12:17 PM

Quote:

Originally Posted by ReaperX7

1. It adds to the disk size, as if it's not big enough and we are edging closer to the DVD+R capacity limit. Small stuff is fine, but larger stuff can be bad. I seriously doubt we want Slackware to push a two DVD set, or worse, Dual-Layer DVD, which are a pain in the ass to burn correctly, and not everyone has Blu-Ray Burners.

This was a problem when Slackware DVDs still contained the source tree. Without the source tree there is plenty of space.

Quote:

2. Not everyone will use or need it, even if it rounds out the distribution to cater to desktops, laptops, and servers alike. Is it sane for the system to have it?

Not everyone uses Vim or Emacs or even GIMP, but it is there nonetheless. So I wouldn't count that as an argument. The real question "Is it sane to have it?" is of course valid and for a4z it is sane to have it, and I would say in times where Bluetooth headsets and headsets that connect over USB (read: contain a dedicated soundcard) it certainly is. The question is: Is it possible to enable/disable on the fly (like, chmod +x /etc/rc.d/rc.pulseaudio) without having to recompile other software. I would guess since it is possible to run Arch and other distros with and without Pulseaudio without having to recompile anything that the answer is: Yes.

Quote:

3. Unless it's a mission critical library for a dependency resolution, chances are it may never make it out of SBo into Slackware itself.

Then does it make sense to ask for additions here at all?

Quote:

4. It still has to make it past Patrick. 1, 2, and 3 actually sum up the answer Patrick usually will give, and unless all three, in general example, can get a yes, it's always a unilateral no, and even then it's still on a whim.

Of course. I thought it is the whole point of this thread to suggest stuff, so that it can get discussed and be brought to Mr. Volkerding's (or anyone else from the team) attention.

Quote:

While I'd love to see OpenRC get folded into Slackware, I know it probably won't, even though it can meet everything on the checklist, and doesn't replace a lot from sysvinit, but at least it can be found on SBo.

Certainly it would be nice to have that choice, but I would think it comes down to a matter of taste which of the two one wants to use, both can reliably boot up the system. An inclusion of Pulseaudio on the other hand would solve a problem that can not be solved with plain Alsa.

If the solution in the end is: "those who want it can install it from SBo" or "those who want it can chmod +x rc.pulseaudio" is naturally up to Mr. Volkerding, but asking for it is what this thread is about.

ReaperX7 · 06-10-2015, 12:35 PM

Yes, but also if you learn to set up ALSA properly, you don't really need PulseAudio.

~/.asoundrc and /etc/modprobe.d/alsa.conf are very powerful files to have and use, and can do fairly much the same things PulseAudio does, but it takes reading documentation, learning ALSA configuration syntax, and some trial and error before it works and you never have to set it up again.

Pulse isn't even a hard requirement for anything except Skype anyway, so one less package to deal with. And yes, for the networked audio we still have ESounD... all of which are the bare, yet functional, minimums.

genss · 06-10-2015, 12:48 PM

Quote:

Originally Posted by TobiSGD

I thought it is the whole point of this thread to suggest stuff, so that it can get discussed and be brought to Mr. Volkerding's (or anyone else from the team) attention.

it is
it was suggested
it is not for discussing
now stop forcing it

dugan · 06-10-2015, 12:55 PM

The advantage of including Pulseaudio in Slackware instead of leaving it on SBo is so that the rest of Slackware's applications and libraries can come built with support for it. MPlayer, Audacious and gst-plugins-good, for example. I really don't see any drawbacks to including it (without necessarily having it running by default), as it's so easy to turn on and off.