Thread: [Alsa-user] No soundcards found - but only kernel 3.x
Brought to you by:
perex
From: User <pk...@un...> - 2013-01-22 13:19:57
|
Hello, May be someone can have a clue to this problem: ALSA on a SB Live! using kernel 2.6.xx is PERFECT. No problems at all. **BUT** on the very SAME SYSTEM (same perms on /dev /proc is fine and /sys is ok as well - and the same module loading sequence is used just fine) where THE ONLY UNIQUE diff is the kernel version.... Where version 2.6.xx is PERFECT, every version 3.x is LOADING JUST FINE, but ALSA CAN NOT FIND A SOUNDCARD -- BUT!!!! note that this detail is driving me nuts... - ALSA_OSS CAN!!! AND IS JUST PERFECT, where plain ALSA tools (aplay, amix, etc) are just lost without a soundcard found..... ALSA_OSS IS WORKING JUST FINE. E.g. kernel driver ok, devices ok.... but aplay rant: - No soundcards found.... Did I miss something ? UDEV? or some new kernel parmameter out of my understanding ? Perms are fine... the driver is fine... But aplay rant is not... it can not "open" the sound device /dev despite OSS can and ALL STUFF IS OK in kernel 2.6.xx just PERFECT! Any hint is welcome. Regards Thanx. |
From: Ralf M. <ral...@al...> - 2013-01-22 13:43:51
|
When I switched from 2.6 to 3.x I don't run into issues. Btw. there wasn't much difference, it was announced that the step from 2.6 to 3.x isn't such a step as for DE versions, e.g. from GNOME 2 to GNOME 3. I compiled the kernel-rt with the config of the 2.6 kernel and run make oldconfig. No trouble here. |
From: User <pk...@un...> - 2013-01-22 14:01:21
|
> When I switched from 2.6 to 3.x I don't run into issues. Btw. there wasn't > much difference, it was announced that the step from 2.6 to 3.x isn't such > a step as for DE versions, e.g. from GNOME 2 to GNOME 3. > > I compiled the kernel-rt with the config of the 2.6 kernel and run make > oldconfig. > > No trouble here. > Well, I can not use THE SAME KERNEL CONFIG as they differ quite a lot. The whole BASIC .config is the same but my DOUBT is the setting about "DEPRECATED SYSFS" which I tried to disable/enable via kern.cmd.line.parm. But no effect, same result. Also IAM **NOT** running UDEV in 3.x and not in 2.x of course. To keep things equal i left hotplug but my guess is not about UDEV. Not hotplug neither. I have traced back the issue down to the "open" function in alsa-lib where the applets (aplay...) are FAILING to "open" the device. But the device is there, perms are ok as well.... still trying to figure out anything out of this.... ALSA_OSS is playing just perfect like nothing wrong. But any "hw" related open is failing. Thanx a lot Any hint very mu.welcm. |
From: Ralf M. <ral...@al...> - 2013-01-22 14:33:08
|
On Tue, 22 Jan 2013 15:00:50 +0100, User <pk...@un...> wrote: > Well, I can not use THE SAME KERNEL CONFIG as they differ quite > a lot. You can, you only need to run make oldconfig. > Also IAM **NOT** running UDEV Can you load the drivers manually? modprobe snd-foo |
From: User <pk...@un...> - 2013-01-22 14:42:22
|
> You can, you only need to run make oldconfig. That would not allow me to select the new option settings. What I do is to "re-use" the old as the new base. Reconfigure new settings from this >> Also IAM **NOT** running UDEV > Can you load the drivers manually? modprobe snd-foo Yes, perfectly, OSS is just playing flawless. But aplay, amixer can not "open" any device. Rant: No soundcards found. So i diverted to option DEPRECATED SYSFS but wo/effect. Devices in /dev are fine. The "old" kernel 2.x is perfect. The new modules are loading ( and playing via OSS) but not playing via "hw" like devices... Which require "open" func. I have no clue so far. But Thanx a lot, any ideia always led to something |
From: Ralf M. <ral...@al...> - 2013-01-22 14:43:46
|
On Tue, 22 Jan 2013 12:34:06 +0100, User <pk...@ma...> wrote: > Ralf Mardorf(ral...@al...)@2013.01.22 15:20:27 +0100: >> On Tue, 22 Jan 2013 15:00:50 +0100, User <pk...@un...> >> wrote: >> >Well, I can not use THE SAME KERNEL CONFIG as they differ quite >> >a lot. >> >> You can, you only need to run make oldconfig. > > That would not allow me to select the new option settings. > What I do is to "re-use" the old as the new base. > Reconfigure new settings from this But this is what make oldconfig is for. >> >Also IAM **NOT** running UDEV >> >> Can you load the drivers manually? modprobe snd-foo >> > > Yes, perfectly Perhaps you should run UDEV for test purpose. |
From: User <pk...@un...> - 2013-01-22 14:59:35
|
> On Tue, 22 Jan 2013 12:34:06 +0100, User <pk...@ma...> wrote: > > But this is what make oldconfig is for. Well by "new" I always want to see in perfect clear the "new" drivers added and that hints marked [new] which help me a bit to go w/the flow of the "new" stuff. I'm used to this about a decade or so... die hard hab. > > Perhaps you should run UDEV for test purpose. > Did that, no effect - I use aplay as soon as the driver is loaded and test `aplay -l | grep card` to make shure the card driver is operational before anyt. else. That is prior to entering level 3 (aka telinit 3) where udev is more likely to enter the game. So it is in fact neutral (and should better be at this point). aplay fails to open the /dev node and so does alsactl, etc.. But from this on, OSS is PERFECT. Even TIMIDITY using OSS is playing like church... just perfect... BUT USING ths OSS layer. NOT ALSA HW devs. Go figure.. still wanting some new direction to try. UDEV makes no diff at all.... "DEPRECATED SYSFS" makes no diff as well I tried the option PCI=USE_CRS x NOCRS but no effect as well. MORE IDEAS? TaTanhx |
From: John H. <jc...@th...> - 2013-01-22 15:58:28
|
On 22/01/13 14:59, User wrote: > Did that, no effect - I use aplay as soon as the driver > is loaded and test `aplay -l | grep card` to make shure > the card driver is operational before anyt. else. You should look in /proc/asound instead: aplay requires quite a lot of things to be working, /proc/asound will exist even when only ALSA is present. > That is prior to entering level 3 (aka telinit 3) where > udev is more likely to enter the game. udev actually kicks in before you even get into single user, a system using udev uses it to discover almost all the hardware. The major distros use it because it's more reliable. Even my RaspberryPi uses it. jch jch |
From: User <pk...@un...> - 2013-01-22 16:16:02
|
> You should look in /proc/asound instead: aplay requires quite a lot of > things to be working, /proc/asound will exist even when only ALSA is > present. Please don't get me wrong here. I AM **NOT** using the DEPRECATED OSS drivers. (period) I AM USING THE ALSA OSS LAYER - ONLY ALSA. and they all load and run properly. just fine. Sequencer, clock, etc... OSS devices ( in /dev ) can be opened (via alsa-lib open func) but HW devices ( in /dev and /dev/snd ) are failing (via same alsa-lib open func) ** ALL DEVICE NODES ARE FIXED ** ** INDEED THIS SYSTEM DOES NOT REQUIRES UDEV AT ALL** ** UDEV IS TOTALLY AND COMPLETELY USELESS in this system** **BUT** for the sake of testing I DID USED IT a bit.. BUT KEEPING THE /dev tree INTACT and EXACTLY THE SAME as it is/was (perms/nodes,etc) As today seems that a lot of folks are biased towards the UDEV thing.... I tried... > udev actually kicks in before you even get into single user, a system > using udev uses it to discover almost all the hardware. The major > distros use it because it's more reliable. Even my RaspberryPi uses it. I see this situation... but **IF** you use UDEV to populate /dev. This /dev nodes are FIXED. UDEV indeed makes no diff **UNLESS** some changes are required and RELIES ON UDEV TO DO SO. I am not aware of any... if anyone can identify that, great... That would be another test frontier... Thanx |
From: John H. <jc...@th...> - 2013-01-22 17:18:18
|
On 22/01/13 16:15, User wrote: >> You should look in /proc/asound instead: aplay requires quite a lot of >> > things to be working, /proc/asound will exist even when only ALSA is >> > present. > Please don't get me wrong here. > I AM **NOT** using the DEPRECATED OSS drivers. (period) > > I AM USING THE ALSA OSS LAYER - ONLY ALSA. > and they all load and run properly. just fine. > Sequencer, clock, etc... Please don't shout at me. I'm suggesting that instead of aplay -l that you look in /proc/asound instead: aplay requires a lot of things to be working before it reports anything at all. /proc/asound will be there even if nothing works and will certainly include useful information even when aplay doesn't do anything useful. > As today seems that a lot of folks are biased towards the UDEV thing.... > I tried... It's not bias, it's a question of using what is known to work. Note that among other things, udev handles the cases where the major and minor numbers for a device aren't fixed. You may or may not be falling foul of this. jch |
From: Ralf M. <ral...@al...> - 2013-01-22 17:25:50
|
On Tue, 22 Jan 2013 17:52:19 +0100, John Haxby <jc...@th...> wrote: > Please don't shout at me. I suspect the OP doesn't should at you. Perhaps the OP should mark overcautious pointers with "_ _" (_some words_) instead of using capital letters. |
From: User <pk...@un...> - 2013-01-22 17:52:54
|
> On 22/01/13 16:15, User wrote: > > Please don't shout at me. COOL ;) I never shout. it is just BOLD to call ATTN. Never shout. This place is to cool people and ideas Even in IRC i never shout. But some folks are used to think BOLD as shout. Not here;-) |
From: Ralf M. <ral...@al...> - 2013-01-22 18:01:37
|
On Tue, 22 Jan 2013 18:52:30 +0100, User <pk...@un...> wrote: >> On 22/01/13 16:15, User wrote: >> >> Please don't shout at me. > > COOL ;) I never shout. it is just BOLD to call ATTN. > > Never shout. > This place is to cool people and ideas > > Even in IRC i never shout. > But some folks are used to think BOLD as shout. > > Not here;-) While I spelled "shout" incorrectly, you anyway should do it as I explained it. _Use the "_-sign" to call attention_ In the context it was absolutely clear that you didn't shout, but some people are accustomed to Internet policies. |
From: User <pk...@un...> - 2013-01-22 18:00:42
|
> I'm suggesting that instead of aplay -l that you look in /proc/asound > instead: aplay requires a lot of things to be working before it reports > anything at all. /proc/asound will be there even if nothing works and > will certainly include useful information even when aplay doesn't do > anything useful. Have posted contents of asound in this thread bottom. Seems ALL is OK. but aplay fails to open the /dev node > It's not bias, it's a question of using what is known to work. Note > that among other things, udev handles the cases where the major and > minor numbers for a device aren't fixed. You may or may not be falling > foul of this. Well, shure it works but it is not a needed stuff. About more than a decade without it and ALSA was PERFECT - really. JACK+ALSA was a combination without much trouble. If UDEV is causing this problem..... hmmmm I can not be shure so far. The kernel driver seems to me the cause - WHY it can open the /dev node in version 2.6x but **not** in version(s) 3.x ? It is the same device node, same perm, same MAJOR/MINOR... identical. That is my/the problem... driving me nuts :) The driver internals changed quite a bit. |
From: Takashi I. <ti...@su...> - 2013-01-23 08:12:54
|
At Tue, 22 Jan 2013 18:00:13 +0000 (UTC), User wrote: > > > I'm suggesting that instead of aplay -l that you look in /proc/asound > > instead: aplay requires a lot of things to be working before it reports > > anything at all. /proc/asound will be there even if nothing works and > > will certainly include useful information even when aplay doesn't do > > anything useful. > > Have posted contents of asound in this thread bottom. > Seems ALL is OK. but aplay fails to open the /dev node > > > > It's not bias, it's a question of using what is known to work. Note > > that among other things, udev handles the cases where the major and > > minor numbers for a device aren't fixed. You may or may not be falling > > foul of this. > > Well, shure it works but it is not a needed stuff. > > About more than a decade without it and ALSA was PERFECT - really. > JACK+ALSA was a combination without much trouble. > > If UDEV is causing this problem..... hmmmm I can not be shure so far. > > The kernel driver seems to me the cause - WHY it can open the /dev node > in version 2.6x but **not** in version(s) 3.x ? > It is the same device node, same perm, same MAJOR/MINOR... identical. > > That is my/the problem... driving me nuts :) > The driver internals changed quite a bit. Make sure that you do *not* set CONFIG_SND_DYNAMIC_MINORS=y. If this option is set, the dynamic device file assignment like udev becomes mandatory. BTW, this option is forcibly set if you have CONFIG_SND_HDA_CODEC_HDMI=y because HDMI requires more PCM devices than the static devices may have. Takashi |
From: User <pk...@un...> - 2013-01-23 14:22:10
|
> Make sure that you do *not* set CONFIG_SND_DYNAMIC_MINORS=y. If this > option is set, the dynamic device file assignment like udev becomes > mandatory. In version(s) 2.6.X => Dynamic device file minor numbers *IS_NOT* set In version(s) 3.x.x: -- Preclaim OSS device numbers **is_set** -- Dynamic device file minor numbers **MANDATORY_SET** (as using a RADEON MB, as you said, HDMI promoted that) -- Support old ALSA API **is_set** > BTW, this option is forcibly set if you have > CONFIG_SND_HDA_CODEC_HDMI=y because HDMI requires more PCM devices > than the static devices may have. > Takashi A CLOSER look at both shows that despite they look the same, the numbering order schema in fact differ... and the driver, it seems, can not cope with that change (need UDEV to do so ???) ALSA Driver Version 1.0.17 ALSA Driver Version 1.0.25 0: [ 0] : control 11: [ 0] : control 1: : sequencer 1: : sequencer 8: [ 0- 0]: raw midi 2: [ 0- 0]: raw midi 16: [ 0- 0]: digital audio playback 9: [ 0- 0]: digital audio playback 17: [ 0- 1]: digital audio playback 7: [ 0- 1]: digital audio playback 18: [ 0- 2]: digital audio playback 5: [ 0- 2]: digital audio playback 19: [ 0- 3]: digital audio playback 3: [ 0- 3]: digital audio playback 24: [ 0- 0]: digital audio capture 10: [ 0- 0]: digital audio capture 25: [ 0- 1]: digital audio capture 8: [ 0- 1]: digital audio capture 26: [ 0- 2]: digital audio capture 6: [ 0- 2]: digital audio capture 27: [ 0- 3]: digital audio capture 4: [ 0- 3]: digital audio capture 33: : timer 33: : timer 64: [ 2] : control 14: [ 2] : control 72: [ 2- 0]: raw midi 13: [ 2- 0]: raw midi 73: [ 2- 1]: raw midi 12: [ 2- 1]: raw midi Well if that is the problem, and I NEED HDMI/RADEON ... How can I live with that problem ? Without UDEV ? - Can I just change the MINOR/MAJOR /dev entries to get rid of UDEV ? Or am I forcible to use udev to adjust this detail ? That start to gave me some light :-) Thanx a lot. |
From: Takashi I. <ti...@su...> - 2013-01-23 15:20:21
|
At Wed, 23 Jan 2013 14:21:47 +0000 (UTC), User wrote: > > > Make sure that you do *not* set CONFIG_SND_DYNAMIC_MINORS=y. If this > > option is set, the dynamic device file assignment like udev becomes > > mandatory. > > In version(s) 2.6.X => Dynamic device file minor numbers *IS_NOT* set > > In version(s) 3.x.x: > -- Preclaim OSS device numbers **is_set** > -- Dynamic device file minor numbers **MANDATORY_SET** > (as using a RADEON MB, as you said, HDMI promoted that) > -- Support old ALSA API **is_set** > > > BTW, this option is forcibly set if you have > > CONFIG_SND_HDA_CODEC_HDMI=y because HDMI requires more PCM devices > > than the static devices may have. > > Takashi > > A CLOSER look at both shows that despite they look the same, > the numbering order schema in fact differ... and the driver, > it seems, can not cope with that change (need UDEV to do so ???) > > ALSA Driver Version 1.0.17 ALSA Driver Version 1.0.25 > 0: [ 0] : control 11: [ 0] : control > 1: : sequencer 1: : sequencer > 8: [ 0- 0]: raw midi 2: [ 0- 0]: raw midi > 16: [ 0- 0]: digital audio playback 9: [ 0- 0]: digital audio playback > 17: [ 0- 1]: digital audio playback 7: [ 0- 1]: digital audio playback > 18: [ 0- 2]: digital audio playback 5: [ 0- 2]: digital audio playback > 19: [ 0- 3]: digital audio playback 3: [ 0- 3]: digital audio playback > 24: [ 0- 0]: digital audio capture 10: [ 0- 0]: digital audio capture > 25: [ 0- 1]: digital audio capture 8: [ 0- 1]: digital audio capture > 26: [ 0- 2]: digital audio capture 6: [ 0- 2]: digital audio capture > 27: [ 0- 3]: digital audio capture 4: [ 0- 3]: digital audio capture > 33: : timer 33: : timer > 64: [ 2] : control 14: [ 2] : control > 72: [ 2- 0]: raw midi 13: [ 2- 0]: raw midi > 73: [ 2- 1]: raw midi 12: [ 2- 1]: raw midi > > Well if that is the problem, and I NEED HDMI/RADEON ... > > How can I live with that problem ? Without UDEV ? > - Can I just change the MINOR/MAJOR /dev entries to get > rid of UDEV ? Or am I forcible to use udev to adjust this detail ? It's a matter of device number assignment. You can achieve it easily even without udev manually or automatically by some script. For example, in the new case, minor#5 corresponds to /dev/snd/pcmC0D2p: 5: [ 0- 2]: digital audio playback then you need to create a device file like mknod /dev/snd/pcmC0D2p c 116 5 Write a script to call for each line of /proc/asound/devices and call it in an init script after loading the sound modules. Takashi |
From: User <pk...@un...> - 2013-01-23 15:40:10
|
> It's a matter of device number assignment. You can achieve it easily > even without udev manually or automatically by some script. > > For example, in the new case, minor#5 corresponds to > /dev/snd/pcmC0D2p: > 5: [ 0- 2]: digital audio playback > > then you need to create a device file like > mknod /dev/snd/pcmC0D2p c 116 5 > > Write a script to call for each line of /proc/asound/devices and call > it in an init script after loading the sound modules. > Takashi Thanks a lot Takashi, I will do that to avoid using udev solely to this. But one question remains: - If they are dyn. assgn. can I count that they will de facto be the same next boot (remember that in this particular case I have my own rc.x carefully crafted to load my mods.) e.g. can i be shure they will repeat next boot? OR.. i assume *NOT* and traverse the new schema to assign ? TX |
From: Takashi I. <ti...@su...> - 2013-01-23 16:45:43
|
At Wed, 23 Jan 2013 15:39:45 +0000 (UTC), User wrote: > > > > It's a matter of device number assignment. You can achieve it easily > > even without udev manually or automatically by some script. > > > > For example, in the new case, minor#5 corresponds to > > /dev/snd/pcmC0D2p: > > 5: [ 0- 2]: digital audio playback > > > > then you need to create a device file like > > mknod /dev/snd/pcmC0D2p c 116 5 > > > > Write a script to call for each line of /proc/asound/devices and call > > it in an init script after loading the sound modules. > > Takashi > > Thanks a lot Takashi, I will do that to avoid using udev > solely to this. But one question remains: > > - If they are dyn. assgn. can I count that they will de facto > be the same next boot (remember that in this particular case > I have my own rc.x carefully crafted to load my mods.) The minor number assignment _should_ be same if the module loading and initialization order is static, unchanged in different boots. But writing a script for doing the above would be trivial, too... Takashi |
From: Dominique M. <dom...@vt...> - 2013-01-23 16:59:21
|
Le Wed, 23 Jan 2013 15:39:45 +0000 (UTC), User <pk...@un...> a écrit : > > > It's a matter of device number assignment. You can achieve it > > easily even without udev manually or automatically by some script. > > > > For example, in the new case, minor#5 corresponds to > > /dev/snd/pcmC0D2p: > > 5: [ 0- 2]: digital audio playback > > > > then you need to create a device file like > > mknod /dev/snd/pcmC0D2p c 116 5 > > > > Write a script to call for each line of /proc/asound/devices and > > call it in an init script after loading the sound modules. > > Takashi > > Thanks a lot Takashi, I will do that to avoid using udev > solely to this. But one question remains: > > - If they are dyn. assgn. can I count that they will de facto > be the same next boot (remember that in this particular case > I have my own rc.x carefully crafted to load my mods.) The basic syntax is the same than in /etc/modprobe.d/*, or whatever you are using. Its all about loading modules with the wanted parameters. The options for the sound modules are explained in the kernel documentation, which is part of the kernel sources (or in the alsa-drivers doc). In ALSA-configuration.txt. It is some other files as well. I recommend you to only use modules for the snd* modules (inclusive snd). That way, you can use /etc/init.d/alsasound, which is an udec wrapper, or custom scripts. When like you, you are not using udev, you must make some script to load the modules. In both cases, you can use all the options described in the doc. With multiple sound cards, the most important is index=n, where n is the card number beginning with 0 for the first card. Pay also attention to the cards_limit=m option for snd, where m is the total number of sound cards beginning with 1 for the first card. When using custom script, I am not sure if loading snd as first is a good idea, because it can, and maybe will, assign the slots for the cards before the modules for the cards get loaded, which can result into the index=n options getting ignored and random card order. It is what append if snd is into the kernel, no sound related boot parameters, and the other modules as modules. With modules into the kernel, you can also do it, but you have to pass all the modules options as boot parameters with grub or lilo. I never experimented it. Ciao, Dominique > > e.g. can i be shure they will repeat next boot? > OR.. i assume *NOT* and traverse the new schema to assign ? > > TX > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills > current with LearnDevNow - 3,200 step-by-step video tutorials by > Microsoft MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > Alsa-user mailing list > Als...@li... > https://lists.sourceforge.net/lists/listinfo/alsa-user -- "We have the heroes we deserve." |
From: User <pk...@un...> - 2013-01-23 16:39:37
|
- NOTE: I am asking if they (WILL) repeat because if I can count w/that things are *REALLY* reduced to this simple: mknod /dev/snd/${DEV} c 116 ${NODE} # ALSA k2.x devs ALSA k3.x devs controlC0 116 0 controlC0 116 11 seq 116 1 seq 116 1 midiC0D0 116 8 midiC0D0 116 2 pcmC0D0p 116 16 pcmC0D0p 116 9 pcmC0D1p 116 17 pcmC0D1p 116 7 pcmC0D2p 116 18 pcmC0D2p 116 5 pcmC0D3p 116 19 pcmC0D3p 116 3 pcmC0D0c 116 24 pcmC0D0c 116 10 pcmC0D1c 116 25 pcmC0D1c 116 8 pcmC0D2c 116 26 pcmC0D2c 116 6 pcmC0D3c 116 27 pcmC0D3c 116 4 timer 116 33 timer 116 33 controlC2 116 64 controlC2 116 14 midiC2D0 116 72 midiC2D0 116 13 midiC2D1 116 73 midiC2D1 116 12 to go back/for from kernel vers. TX |
From: User <pk...@un...> - 2013-01-23 17:08:21
|
> The minor number assignment _should_ be same if the module loading > and initialization order is static, unchanged in different boots. > But writing a script for doing the above would be trivial, too... > Takashi GOOD! very good :-) Shure thing. Even better if they will repeat even w/dyn. assgn. (e.g. they follow a regular dyn. criteria of assign) Avoiding a perl/awk/sh to hash remap those nodes and going plain directly "mknods" should be faster/safer. I need that in a busybox like thing as well... the lesser the better, the faster too. (aka service boot to suite multiple kerns) I've posted the direct like mknod sequence... a trivial fix wo/complications, good. Your expertise "gotcha" at first glance. Thank you very, very much Takashi! :-) Tx |
From: Dominique M. <dom...@vt...> - 2013-01-23 17:39:27
|
Le Wed, 23 Jan 2013 17:07:53 +0000 (UTC), User <pk...@un...> a écrit : > > The minor number assignment _should_ be same if the module loading > > and initialization order is static, unchanged in different boots. > > But writing a script for doing the above would be trivial, too... > > Takashi > > GOOD! very good :-) Shure thing. > > Even better if they will repeat even w/dyn. assgn. > (e.g. they follow a regular dyn. criteria of assign) > > Avoiding a perl/awk/sh to hash remap > those nodes and going plain directly "mknods" > should be faster/safer. > > I need that in a busybox like thing as well... > the lesser the better, the faster too. > (aka service boot to suite multiple kerns) > > I've posted the direct like mknod sequence... > a trivial fix wo/complications, good. > > Your expertise "gotcha" at first glance. > Thank you very, very much Takashi! :-) > Tx > Yes, me too was learning something new today. Thank you both of you! Dominique > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills > current with LearnDevNow - 3,200 step-by-step video tutorials by > Microsoft MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > Alsa-user mailing list > Als...@li... > https://lists.sourceforge.net/lists/listinfo/alsa-user -- "We have the heroes we deserve." |
From: User <pk...@un...> - 2013-01-23 18:00:03
|
Thank you too Dom. your attention was very welcome too. But lucky me the problem seems solved for good. Good to know that you have profit from this problem too... The folks here are sometimes busy. sometimes too! busy but no voice here is left in the dark :-) Thank you too. Tx |
From: Clemens L. <cla...@go...> - 2013-01-22 16:36:07
|
User wrote: > ALSA on a SB Live! using kernel 2.6.xx is PERFECT. > **BUT** on the very SAME SYSTEM (same perms on /dev > /proc is fine and /sys is ok as well - and the same > module loading sequence is used just fine) where THE > ONLY UNIQUE diff is the kernel version.... > > Where version 2.6.xx is PERFECT, every version 3.x > is LOADING JUST FINE, but ALSA CAN NOT FIND A > SOUNDCARD > > -- BUT!!!! note that this detail is driving me nuts... > > - ALSA_OSS CAN!!! What drivers are loaded (lsmod)? Are there any files in /proc/asound/? Regards, Clemens |