Actually I don't understand anything about programming, and (just in case) I wasn't being critical either, I just told about my experience using MoManager. I should've guessed those .in extensions served for a particular purpose

By the way, these mini-translations are too long for your blog comment form, so I put them here and commented the post link in the blog post:

This may be something that is not unique to Racy (though it is happening for me on 5.2.2.9 right now) but perhaps someone can shed some light.

I like to run 2 sound cards in my computers so I can route audio from different applications to different places.

So I have "Soundcard A" (which is integrated on the motherboard) and "Soundcard B" (which is a PCI card).

My problem is that the process of establishing the default soundcard appears to be random.

At first I thought that the Multiple Sound Card Wizard just wasn't working, but I see that there is a file at /etc/asound.conf which appears to define the default soundcard.

But it only specifies a card and device NUMBER eg:

defaults.pcm.card 1
defaults.pcm.device 0

Am I looking at the correct file for this?
Note that the cards are not named.

The big problem arises from the fact that at each boot-up the process of allocating the card numbers seems totally random. Sometimes Soundcard A will be given the number 0 and Soundcard B will be given the number 1 and on another boot-up they can be allocated the other way round.

Would it be possible to have the file set the default card by specifying it by name?

Alternatively (and probably the ideal solution), is there a way to ensure that the allocation of number to name remains the same at every boot-up?

UPDATE - Think I may have solved it. Running the ALSA Wizard (despite my reluctance because of the scary dialog that pops up) seems to have enabled me to lock down the allocation of "Card 0" to the integrated soundcard on the motherboard.

I see that lines have been added to the file /etc/modprobe.d/alsa.conf thus:-

The other soundcard does disappear from the options displayed in Multiple Sound Card Wizard when you do this, so I was worried that I may have lost my internal connection to it, but on re-boot they were both there again and on a couple of re-boots the order was staying the same.
I then had to use Multiple Sound Card Wizard (again) to change the default back from "Card 1" to "Card 0". This creates a new file at /etc/asound.conf leaving the previous one there with the suffix "old".

This may be something that is not unique to Racy (though it is happening for me on 5.2.2.9 right now) but perhaps someone can shed some light.

I like to run 2 sound cards in my computers so I can route audio from different applications to different places.

So I have "Soundcard A" (which is integrated on the motherboard) and "Soundcard B" (which is a PCI card).

My problem is that the process of establishing the default soundcard appears to be random.

At first I thought that the Multiple Sound Card Wizard just wasn't working, but I see that there is a file at /etc/asound.conf which appears to define the default soundcard.

But it only specifies a card and device NUMBER eg:

defaults.pcm.card 1
defaults.pcm.device 0

Am I looking at the correct file for this?
Note that the cards are not named.

The big problem arises from the fact that at each boot-up the process of allocating the card numbers seems totally random. Sometimes Soundcard A will be given the number 0 and Soundcard B will be given the number 1 and on another boot-up they can be allocated the other way round.

Would it be possible to have the file set the default card by specifying it by name?

Alternatively (and probably the ideal solution), is there a way to ensure that the allocation of number to name remains the same at every boot-up?

UPDATE - Think I may have solved it. Running the ALSA Wizard (despite my reluctance because of the scary dialog that pops up) seems to have enabled me to lock down the allocation of "Card 0" to the integrated soundcard on the motherboard.

I see that lines have been added to the file /etc/modprobe.d/alsa.conf thus:-

The other soundcard does disappear from the options displayed in Multiple Sound Card Wizard when you do this, so I was worried that I may have lost my internal connection to it, but on re-boot they were both there again and on a couple of re-boots the order was staying the same.
I then had to use Multiple Sound Card Wizard (again) to change the default back from "Card 1" to "Card 0". This creates a new file at /etc/asound.conf leaving the previous one there with the suffix "old".

Yes, that does seem a bit roundabout to fix your problem, but I don't really know any simple fix, other than perhaps adding some documentation._________________http://bkhome.org/news/

Yes, that does seem a bit roundabout to fix your problem, but I don't really know any simple fix, other than perhaps adding some documentation.

My one "onboard's soundcards" use mostly two drivers , especially the snd-intel8x0 + snd-mpu401 or snd-wavefront , sometimes three and there are snd-pcsp and pcspkr kernel modules possible to enable .

This random detection of the modaliases in rc.sysinit probably could get sorted by sort command .

But my experience is that the many triggerings to modprobe drivers queue up before the CPU and get processed by the CPU in a unordered mode even filtering with the sort binary . I observed this especially with one core intel cpus .

a wait function for pup_event_backend_modprobe would look something like

That would enable a script in $HOME/Startup to modprobe the drivers in the wanted order like /root/Startup/Sound.sh .

Code:

#!/bin/sh

#Personal Sound script
# ie to unload modules by the rmmod or modprobe -v commands
# or to load modules by the modprobe [-v] command
# see " [p]man modprobe " for more details .
#It is also advised to run /usr/sbin/bootmanager
# from the System Menu , to force the loading/blacklisting of modules .

#Don't forget to add a line with /etc/init.d/[##_]alsa [start|stop].

#In case on no sound modules loaded,
# the sound applet in the tray (/usr/[local/]bin/retrovol) tends to exit .
#Of course, you can run alsawizard ,too .

If Multiple-Sound-Card-Wizard doesn't find any sound card, it will create a corrupt /etc/asound.conf file if user clicks "OK".

Of course, if it cannot find any sound cards, there is a worse problem somewhere else, so the corrupt asound.conf file doesn't seem as bad by comparison. If the user could fix the initial problem so that a sound card could be found, then run Multiple-Sound-Card-Wizard again to get a good asound.conf file, life would be good.

Unfortunately, Multiple-Sound-Card-Wizard is confused by the bad asound.conf file it created and will not find any sound cards until the bad file is fixed or deleted.

And while asound.conf is bad, aplay, alsamixer, and probably other stuff will fail. So even if the user has fixed the initial problem and perhaps even rebooted, she still will have no sound.

The bad asound.conf file created by Multiple-Sound-Card-Wizard looks like this:

Code:

defaults.pcm.card
defaults.pcm.device

Note that the number at the end of each line is missing, so the next time you run Multiple-Sound-Card-Wizard the first line of the error message will to be:

Code:

ALSA lib conf.c:976:(parse_value) card is not a string

(The line number (976 in the example) will be different for different versions of the ALSA library.)
That error message actually comes from aplay -l, which Multiple-Sound-Card-Wizard calls upon to get its list of sound cards.

alsamixer.bin gives the same error message, but the alsamixer wrapper script gives this error:

Code:

alsamixer.bin: option requires an argument -- 'c'

since it could not find the card number in the /etc/asound.conf file.

Of course, most users probably just run Multiple-Sound-Card-Wizard from the menu, and won't see any error messages unless they look at the /etc/xerrs.log file. Users who run Multiple-Sound-Card-Wizard from within alsawizard will never see any error messages, since that script sends them off to /dev/null.

The proposed fix simply places a message in the list window stating that the utility was unable to find any sound card, and it removes the "OK" button from the dialog. No asound.conf file is created or overwritten when the user clicks "Cancel".

There is also a small change to keep /tmp/mscw.tmp from growing each time the utility is used.

The attached patch is based on the current PET at:
http://distro.ibiblio.org/quirky/pet_packages-common/mscw-1.pet

I was informed that we have to use gxmessage instead of xmessage for non-English Puppy. So, I have built Wary and Racy 5.2.90 with gxmessage (and xmessage a symlink to gxmessage).

However, disciple has posted to my blog that this in the X resources, I presume in /root/.Xresources, will enable xmessages to display non-English text properly:

Code:

*international: true

Is this true?

Note, Wary and Racy still have xmessage, at /usr/X11R7/bin -- but the /usr/bin/xmessage symlink is found beforehand. So, just delete the symlink and you have the old xmessage back._________________http://bkhome.org/news/

I did a full install of Racy 5.2.90.
I haven't had any problems.
I changed to icewm and added "Desksetup Templates for Desk Icons" from
Slacko which allows removing all the desktop and drive icons.
Racy 5.2.90 seems to be rock solid, making small changes is fun though