At Tue, 22 Jan 2013 18:00:13 + (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
User wrote:
/proc/asound DETAILS (apply same to kernel 2.x 3x):
0: [ 0] : control
1:: sequencer
8: [ 0- 0]: raw midi
16: [ 0- 0]: digital audio playback
These device numbers look OK.
Please show the output of ls -l /dev/snd/ for both kernels.
Regards,
Clemens
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
User wrote:
/proc/asound DETAILS (apply same to kernel 2.x 3x):
0: [ 0] : control
1:: sequencer
8: [ 0- 0]: raw midi
16: [ 0- 0]: digital audio playback
These device numbers look OK.
Please show the output of ls -l /dev/snd/ for both kernels.
The ALSA_OSS layer in
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
- 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 0controlC0 116 11
seq 116 1seq116 1
midiC0D0 116 8
At Wed, 23 Jan 2013 15:39:45 + (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
Le Wed, 23 Jan 2013 15:39:45 + (UTC),
User pkt...@unlimitedmail.org 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:
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.
Le Wed, 23 Jan 2013 17:07:53 + (UTC),
User pkt...@unlimitedmail.org 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
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
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
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.
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
On Tue, 22 Jan 2013 15:00:50 +0100, User pkt...@unlimitedmail.org 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
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
On Tue, 22 Jan 2013 12:34:06 +0100, User pk...@mailshack.com wrote:
Ralf Mardorf(ralf.mard...@alice-dsl.net)@2013.01.22 15:20:27 +0100:
On Tue, 22 Jan 2013 15:00:50 +0100, User pkt...@unlimitedmail.org
wrote:
Well, I can not use THE SAME KERNEL CONFIG as they differ quite
a lot.
You can,
On Tue, 22 Jan 2013 12:34:06 +0100, User pk...@mailshack.com 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
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,
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
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
What drivers are loaded (lsmod)?
Are there any files in /proc/asound/?
LSMOD by grep snd (sorted)
ac97_bus1544 1 snd_ac97_codec
rtc10148 1 snd_rtctimer
snd48556 18 snd_pcm_oss,snd_seq_oss,snd_mixer_oss,
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
On Tue, 22 Jan 2013 17:52:19 +0100, John Haxby j...@thehaxbys.co.uk 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.
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;-)
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
On Tue, 22 Jan 2013 18:52:30 +0100, User pkt...@unlimitedmail.org 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
/proc/asound DETAILS (apply same to kernel 2.x 3x):
(but of course the alsa driver version differs - the rest equals)
0 [CA0106 ]: CA0106 - CA0106
Live! 7.1 24bit [SB0410] at 0xe800 irq 20
2 [VirMIDI]: VirMIDI - VirMIDI
Virtual MIDI
Le Tue, 22 Jan 2013 22:06:46 +0100,
Dominique Michel dominique.mic...@vtxnet.ch a écrit :
Le Tue, 22 Jan 2013 12:42:50 + (UTC),
User pkt...@unlimitedmail.org a écrit :
Hello,
May be someone can have a clue to this problem:
ALSA on a SB Live! using kernel 2.6.xx is PERFECT.
Today I turn on my PC and got no sound, this message durring boot:
Restoring ALSA Levels [BUSY]
/usr/sbin/alsactl: load_state:1686: No soundcards found... [FAIL]
No sound device or similar content in /proc/asound/cards file. Some
difference I have found in kernel.log file. Today:
kernel: [
Perhaps you have not enough interrupts in your mainboard. Try to
disable unused integrated devices like com ports, LPT etc. in BIOS. I
had same problem with my LAN.
20 апреля 2012 г. 15:26 пользователь Блогер blo...@ngs.ru написал:
Today I turn on my PC and got no sound, this message durring
31 matches
Mail list logo
