possible problems with rc6 aplay

possible problems with rc6 aplay

[patrick reardon]

hi everyone:

i'm running on a PIII with kernel 2.4.18 and Alsa 0.9.0rc6 and a Hammerfall 9636 card. 
Alsa has been working fine for the last year, or so it seems.  recently a scsi CD burner
was installed.  i have some recordings of live performances made with "arecord", version
0.9.0beta8a.  they play back just fine, but when i tried to burn them to CD, they were low
by about 2 to 3 half steps.  

Joerg Shilling suggested that Alsa was writing the wrong headers.  so i upgraded to rc6
and on the first try on each of the old WAV files, "aplay" also played them too slowly. 
however, on subsequent runs, everything was fine again.  i don't understand this behaviour
at all.

someone on LAU suggested that since it was too low by about 2-3 half steps, data was being
recorded at 48000 but Alsa thought it was at 44100.  

info in /proc/asound/hammerfall/rme9652:

------------snip-------------
.
.
Latency: 4096 samples (2 periods of 16384 bytes)
Hardware pointer (frames): 0
Passthru: no
Clock mode: autosync
Pref. sync source: ADAT1

IEC958 input: Coaxial
IEC958 output: Coaxial only
IEC958 quality: Consumer
IEC958 emphasis: off
IEC958 Dolby: off
IEC958 sample rate: error flag set

ADAT Sample rate: 44100Hz
.
.
---------snip-----------------


for months up until about an hour ago the ADAT sample rate read 48000.  in that hour i
changed my .asoundrc from 


-----------snip---------------
pcm.hammerfall {	#"hammerfall" is the alias for "snd-rme9652" in /etc/modules.conf
	type hw
	card0
}

ctl.hammerfall {
	type hw
	card0
}
-----------snip---------------


to the following


-----------snip---------------

pcm.rme9652 {   #changed from "hammerfall" to "rme9652" on 12.15.2002
   type hw
   card 0
}

ctl.rme9652 {   #same as above comment
   type hw
   card 0
}
---------snip-----------------


after the .asoundrc change i recorded a fresh WAV and burned it to CD but with the same
problem -- too slow.  also, with the new .asoundrc, version rc6 plays WAV's recorded with
the old .asoundrc and version rc6 a little too fast.  i'm at a loss for new ideas to debug
this.

can anyone enlighten me about this, or does anyone know where i can download some
reference WAV files (for example, a middle C tone) to check whether the burning problem
might involve Alsa or whether it's something else in my setup?

any pointers would be greatly appreciated.

tia,
patrick


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: possible problems with rc6 aplay

[Mark Knecht]

Patrick,
   I'm not an Alsa expert so take all of this with a grain of salt. The
difference between 48K and 44.1K is indeed about a whole step, so that's
consistent with your results. You have 48000 samples that are supposed
to take one second to play, but you are taking more than one second to
play then. The result is the output tuning is low.

   Since CDs are ALWAYS 44.1K, this would make sense when you burn a CD.
You could get around this by resampling the 48K input down to 44.1K.
There is some open source software for doing that.

   This will change the quality of the sound a bit, and is the main
reason I always work at 44.1K.

   I don't remember how to do it, but there is an option I've seen in
some .asoundrc files that allows you to set the frequency of the
Hammerfall. I have two Hammerfalls, so I suppose I had better learn to
do that one of these days.

Good luck,
Mark


On Sun, 2002-12-15 at 13:59, patrick reardon wrote:
> hi everyone:
> 
> i'm running on a PIII with kernel 2.4.18 and Alsa 0.9.0rc6 and a Hammerfall 9636 card. 
> Alsa has been working fine for the last year, or so it seems.  recently a scsi CD burner
> was installed.  i have some recordings of live performances made with "arecord", version
> 0.9.0beta8a.  they play back just fine, but when i tried to burn them to CD, they were low
> by about 2 to 3 half steps.  
> 
> Joerg Shilling suggested that Alsa was writing the wrong headers.  so i upgraded to rc6
> and on the first try on each of the old WAV files, "aplay" also played them too slowly. 
> however, on subsequent runs, everything was fine again.  i don't understand this behaviour
> at all.
> 
> someone on LAU suggested that since it was too low by about 2-3 half steps, data was being
> recorded at 48000 but Alsa thought it was at 44100.  
> 
> info in /proc/asound/hammerfall/rme9652:
> 
> ------------snip-------------
> .
> .
> Latency: 4096 samples (2 periods of 16384 bytes)
> Hardware pointer (frames): 0
> Passthru: no
> Clock mode: autosync
> Pref. sync source: ADAT1
> 
> IEC958 input: Coaxial
> IEC958 output: Coaxial only
> IEC958 quality: Consumer
> IEC958 emphasis: off
> IEC958 Dolby: off
> IEC958 sample rate: error flag set
> 
> ADAT Sample rate: 44100Hz
> .
> .
> ---------snip-----------------
> 
> 
> for months up until about an hour ago the ADAT sample rate read 48000.  in that hour i
> changed my .asoundrc from 
> 
> 
> -----------snip---------------
> pcm.hammerfall {	#"hammerfall" is the alias for "snd-rme9652" in /etc/modules.conf
> 	type hw
> 	card0
> }
> 
> ctl.hammerfall {
> 	type hw
> 	card0
> }
> -----------snip---------------
> 
> 
> to the following
> 
> 
> -----------snip---------------
> 
> pcm.rme9652 {   #changed from "hammerfall" to "rme9652" on 12.15.2002
>    type hw
>    card 0
> }
> 
> ctl.rme9652 {   #same as above comment
>    type hw
>    card 0
> }
> ---------snip-----------------
> 
> 
> after the .asoundrc change i recorded a fresh WAV and burned it to CD but with the same
> problem -- too slow.  also, with the new .asoundrc, version rc6 plays WAV's recorded with
> the old .asoundrc and version rc6 a little too fast.  i'm at a loss for new ideas to debug
> this.
> 
> can anyone enlighten me about this, or does anyone know where i can download some
> reference WAV files (for example, a middle C tone) to check whether the burning problem
> might involve Alsa or whether it's something else in my setup?
> 
> any pointers would be greatly appreciated.
> 
> tia,
> patrick
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: possible problems with rc6 aplay

[Paul Davis]

>Latency: 4096 samples (2 periods of 16384 bytes)
>Hardware pointer (frames): 0
>Passthru: no
>Clock mode: autosync
>Pref. sync source: ADAT1
>
>IEC958 input: Coaxial
>IEC958 output: Coaxial only
>IEC958 quality: Consumer
>IEC958 emphasis: off
>IEC958 Dolby: off
>IEC958 sample rate: error flag set
>
>ADAT Sample rate: 44100Hz

if you're hammerfall is configured as shown above (and no, the name
change makes no difference), then the SR that it uses will be
determined by your external converter connected to the first ADAT
port. nothing that ALSA does (or any program using ALSA does) will
alter the SR. thats because you are synced to ADAT1, not the card's
internal clock, thus the SR is determined by the clock signal arriving
at ADAT1, which presumably comes from a converter somewhere back up
the ADAT chain.

its been on my to-do list for some time to make "master" the default
clock mode on the hammerfall, which avoids any ambiguity about the
sample rate used by the card. i've held back because its really not
the right option for most studio-ish users, who have external
converters that probably have rate switches on them and they expect
the hammerfall to follow the switch setting.

does any of this make it any clearer? its really a bit of problem that
the rate setting code doesn't do a full 100% check on all this
stuff. an app can set the rate to 44100, and appear to have succeeded,
but it will have no difference on the actual rate if the sync source
is not the clock's internal clock. this is true, btw, for most digital
cards. if you tried to record at 44100, but your external converters
were running at 48kHz (as you suggest they have been), then the
recordings will be at 48kHz with the sync source set as shown above.

--p




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: possible problems with rc6 aplay

[Mark Knecht]

Paul,
   I'm using two Hammerfalls in separate boxes. Please try to come up
with a solution, either automatically or by asking questions in some
configuration process, that allows two Linux boxes to choose which to
make the master. It is important in my case.

Thanks,
Mark

On Sun, 2002-12-15 at 19:13, Paul Davis wrote:
> >Latency: 4096 samples (2 periods of 16384 bytes)
> >Hardware pointer (frames): 0
> >Passthru: no
> >Clock mode: autosync
> >Pref. sync source: ADAT1
> >
> >IEC958 input: Coaxial
> >IEC958 output: Coaxial only
> >IEC958 quality: Consumer
> >IEC958 emphasis: off
> >IEC958 Dolby: off
> >IEC958 sample rate: error flag set
> >
> >ADAT Sample rate: 44100Hz
> 
> if you're hammerfall is configured as shown above (and no, the name
> change makes no difference), then the SR that it uses will be
> determined by your external converter connected to the first ADAT
> port. nothing that ALSA does (or any program using ALSA does) will
> alter the SR. thats because you are synced to ADAT1, not the card's
> internal clock, thus the SR is determined by the clock signal arriving
> at ADAT1, which presumably comes from a converter somewhere back up
> the ADAT chain.
> 
> its been on my to-do list for some time to make "master" the default
> clock mode on the hammerfall, which avoids any ambiguity about the
> sample rate used by the card. i've held back because its really not
> the right option for most studio-ish users, who have external
> converters that probably have rate switches on them and they expect
> the hammerfall to follow the switch setting.
> 
> does any of this make it any clearer? its really a bit of problem that
> the rate setting code doesn't do a full 100% check on all this
> stuff. an app can set the rate to 44100, and appear to have succeeded,
> but it will have no difference on the actual rate if the sync source
> is not the clock's internal clock. this is true, btw, for most digital
> cards. if you tried to record at 44100, but your external converters
> were running at 48kHz (as you suggest they have been), then the
> recordings will be at 48kHz with the sync source set as shown above.
> 
> --p
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: possible problems with rc6 aplay

[Martin Langer]

On Sun, Dec 15, 2002 at 08:38:54PM -0800, Mark Knecht wrote:
> Paul,
>    I'm using two Hammerfalls in separate boxes. Please try to come up
> with a solution, either automatically or by asking questions in some
> configuration process, that allows two Linux boxes to choose which to
> make the master. It is important in my case.
> 

What about the amixer switch? You can use it for switching between master,
world, ... modes, but I have only small personal experiences with external
hardware using rme32.

Another problem I see is the frequency of your master mode. In my opinion
you can't set your card to master mode without defining it's frequency
before. On rme32 I have three master three modes (32/44.1/48 kHz). If you
have a freshly loaded driver and switch to master mode at first it's output
frquency is totally undefined. But if you play at first some audio stuff
with your rme32 it's no problem and the card uses this last frequency.

But using master clock mode without defining a frequency before isn't
plausible for me and defining one master mode for each frequency was only a
quick solution by me.

Any comments or better solutions?

martin


> Thanks,
> Mark
> 
> On Sun, 2002-12-15 at 19:13, Paul Davis wrote:
> > >Latency: 4096 samples (2 periods of 16384 bytes)
> > >Hardware pointer (frames): 0
> > >Passthru: no
> > >Clock mode: autosync
> > >Pref. sync source: ADAT1
> > >
> > >IEC958 input: Coaxial
> > >IEC958 output: Coaxial only
> > >IEC958 quality: Consumer
> > >IEC958 emphasis: off
> > >IEC958 Dolby: off
> > >IEC958 sample rate: error flag set
> > >
> > >ADAT Sample rate: 44100Hz
> > 
> > if you're hammerfall is configured as shown above (and no, the name
> > change makes no difference), then the SR that it uses will be
> > determined by your external converter connected to the first ADAT
> > port. nothing that ALSA does (or any program using ALSA does) will
> > alter the SR. thats because you are synced to ADAT1, not the card's
> > internal clock, thus the SR is determined by the clock signal arriving
> > at ADAT1, which presumably comes from a converter somewhere back up
> > the ADAT chain.
> > 
> > its been on my to-do list for some time to make "master" the default
> > clock mode on the hammerfall, which avoids any ambiguity about the
> > sample rate used by the card. i've held back because its really not
> > the right option for most studio-ish users, who have external
> > converters that probably have rate switches on them and they expect
> > the hammerfall to follow the switch setting.
> > 
> > does any of this make it any clearer? its really a bit of problem that
> > the rate setting code doesn't do a full 100% check on all this
> > stuff. an app can set the rate to 44100, and appear to have succeeded,
> > but it will have no difference on the actual rate if the sync source
> > is not the clock's internal clock. this is true, btw, for most digital
> > cards. if you tried to record at 44100, but your external converters
> > were running at 48kHz (as you suggest they have been), then the
> > recordings will be at 48kHz with the sync source set as shown above.
> > 
> > --p
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility 
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 
> 
> 
> 
> -------------------------------------------------------
> This sf.net email is sponsored by:
> With Great Power, Comes Great Responsibility 
> Learn to use your power at OSDN's High Performance Computing Channel
> http://hpc.devchannel.org/
> _______________________________________________
> Alsa-devel mailing list
> Alsa-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
> 
> 

-- 
"2b|!2b"


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: possible problems with rc6 aplay

[Mark Knecht]

Martin,
   That might certainly be an answer. How would this amixer switch get
st in the first place? I wouldn't mind doing it by hand once as long as
it was then loaded after that.

   I'm having an interesting problem with this setup with now that's
probably based in this area. If I bring up these two systems with the
main DAW in Linux, and the slave system in Windows everything is fine.
The DAW controls the frequency via my running jack, but even at first
boot the two sides lock together just fine. 

   If I then boot the DAW into Windows, the two sides start making noise
through the speakers, and if I look at the RME app in Windows on the
slave machine, the frequency is bouncing around and so is the mode
saying it's master or slave. The worst part is I get ugly noise out of
my speakers unless I tell one f the two Windows machines what mode to be
in.

   Is sort of makes sense...

   Going back into Linux solves the noise problem.

Mark


On Mon, 2002-12-16 at 02:17, Martin Langer wrote:
> On Sun, Dec 15, 2002 at 08:38:54PM -0800, Mark Knecht wrote:
> > Paul,
> >    I'm using two Hammerfalls in separate boxes. Please try to come up
> > with a solution, either automatically or by asking questions in some
> > configuration process, that allows two Linux boxes to choose which to
> > make the master. It is important in my case.
> > 
> 
> What about the amixer switch? You can use it for switching between master,
> world, ... modes, but I have only small personal experiences with external
> hardware using rme32.
> 
> Another problem I see is the frequency of your master mode. In my opinion
> you can't set your card to master mode without defining it's frequency
> before. On rme32 I have three master three modes (32/44.1/48 kHz). If you
> have a freshly loaded driver and switch to master mode at first it's output
> frquency is totally undefined. But if you play at first some audio stuff
> with your rme32 it's no problem and the card uses this last frequency.
> 
> But using master clock mode without defining a frequency before isn't
> plausible for me and defining one master mode for each frequency was only a
> quick solution by me.
> 
> Any comments or better solutions?
> 
> martin
> 
> 
> > Thanks,
> > Mark
> > 
> > On Sun, 2002-12-15 at 19:13, Paul Davis wrote:
> > > >Latency: 4096 samples (2 periods of 16384 bytes)
> > > >Hardware pointer (frames): 0
> > > >Passthru: no
> > > >Clock mode: autosync
> > > >Pref. sync source: ADAT1
> > > >
> > > >IEC958 input: Coaxial
> > > >IEC958 output: Coaxial only
> > > >IEC958 quality: Consumer
> > > >IEC958 emphasis: off
> > > >IEC958 Dolby: off
> > > >IEC958 sample rate: error flag set
> > > >
> > > >ADAT Sample rate: 44100Hz
> > > 
> > > if you're hammerfall is configured as shown above (and no, the name
> > > change makes no difference), then the SR that it uses will be
> > > determined by your external converter connected to the first ADAT
> > > port. nothing that ALSA does (or any program using ALSA does) will
> > > alter the SR. thats because you are synced to ADAT1, not the card's
> > > internal clock, thus the SR is determined by the clock signal arriving
> > > at ADAT1, which presumably comes from a converter somewhere back up
> > > the ADAT chain.
> > > 
> > > its been on my to-do list for some time to make "master" the default
> > > clock mode on the hammerfall, which avoids any ambiguity about the
> > > sample rate used by the card. i've held back because its really not
> > > the right option for most studio-ish users, who have external
> > > converters that probably have rate switches on them and they expect
> > > the hammerfall to follow the switch setting.
> > > 
> > > does any of this make it any clearer? its really a bit of problem that
> > > the rate setting code doesn't do a full 100% check on all this
> > > stuff. an app can set the rate to 44100, and appear to have succeeded,
> > > but it will have no difference on the actual rate if the sync source
> > > is not the clock's internal clock. this is true, btw, for most digital
> > > cards. if you tried to record at 44100, but your external converters
> > > were running at 48kHz (as you suggest they have been), then the
> > > recordings will be at 48kHz with the sync source set as shown above.
> > > 
> > > --p
> > > 
> > > 
> > > 
> > > 
> > > -------------------------------------------------------
> > > This sf.net email is sponsored by:
> > > With Great Power, Comes Great Responsibility 
> > > Learn to use your power at OSDN's High Performance Computing Channel
> > > http://hpc.devchannel.org/
> > > _______________________________________________
> > > Alsa-devel mailing list
> > > Alsa-devel@lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/alsa-devel
> > 
> > 
> > 
> > 
> > -------------------------------------------------------
> > This sf.net email is sponsored by:
> > With Great Power, Comes Great Responsibility 
> > Learn to use your power at OSDN's High Performance Computing Channel
> > http://hpc.devchannel.org/
> > _______________________________________________
> > Alsa-devel mailing list
> > Alsa-devel@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/alsa-devel
> > 
> > 
> 
> -- 
> "2b|!2b"




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: possible problems with rc6 aplay

[Paul Davis]

>Martin,
>   That might certainly be an answer. How would this amixer switch get
>st in the first place? I wouldn't mind doing it by hand once as long as
>it was then loaded after that.

what you want is a short startup script (typically in somewhere under
/etc/rc.d, but unfortunately this varies somewhat from linux
distribution to linux distribution). it would look like this:

	#!/bin/sh
	
	HAMMERFALL=0 # change to match the card number of the
		     # Hammerfall, as shown in /proc/asound/cards
        CLOCK_MODE=0 # auto-sync, the default condition.
	CLOCK_MODE_NAME="autosync"

	case $1 in
	     start) if [ -f /some/path/to/this-host-is-master ] ; then
		        CLOCK_MODE=1
			CLOCK_MODE_NAME="master"
		    else
		        CLOCK_MODE=2
			CLOCK_MODE_NAME="word clock"
		    fi  
		    echo "Setting Hammerfall to $CLOCK_MODE_NAME mode ..."
		    amixer -c $HAMMERFALL cset \
			    iface=PCM,name='Sync Mode',numid=7 $CLOCK_MODE
        esac			    
	exit 0

then, just create the file /some/path/to/this-host-is-master on one
machine, and it will automatically set the Master switch when it boots
up. the other machine will remain in AutoSync mode - if they are
connected via word clock, you probably want to change that as well,
using the same script.

if you need more help with this, let me know. this is one of those
areas where linux and its command line orientation proves so powerful
(though to be fair, its probably possible to do something vaguely
similar on windows, but not using such general-purpose tools).

--p


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: possible problems with rc6 aplay

[Takashi Iwai]

At Mon, 16 Dec 2002 08:49:35 -0500,
Paul Davis wrote:
> 
> >Martin,
> >   That might certainly be an answer. How would this amixer switch get
> >st in the first place? I wouldn't mind doing it by hand once as long as
> >it was then loaded after that.
> 
> what you want is a short startup script (typically in somewhere under
> /etc/rc.d, but unfortunately this varies somewhat from linux
> distribution to linux distribution). it would look like this:
> 
> 	#!/bin/sh
> 	
> 	HAMMERFALL=0 # change to match the card number of the
> 		     # Hammerfall, as shown in /proc/asound/cards
>         CLOCK_MODE=0 # auto-sync, the default condition.
> 	CLOCK_MODE_NAME="autosync"
> 
> 	case $1 in
> 	     start) if [ -f /some/path/to/this-host-is-master ] ; then
> 		        CLOCK_MODE=1
> 			CLOCK_MODE_NAME="master"
> 		    else
> 		        CLOCK_MODE=2
> 			CLOCK_MODE_NAME="word clock"
> 		    fi  
> 		    echo "Setting Hammerfall to $CLOCK_MODE_NAME mode ..."
> 		    amixer -c $HAMMERFALL cset \
> 			    iface=PCM,name='Sync Mode',numid=7 $CLOCK_MODE
>         esac			    
> 	exit 0
> 
> then, just create the file /some/path/to/this-host-is-master on one
> machine, and it will automatically set the Master switch when it boots
> up. the other machine will remain in AutoSync mode - if they are
> connected via word clock, you probably want to change that as well,
> using the same script.

the standard alsasound init script can call a card-dependent script
under /etc/alsa.d as the last initialization phase.  for example, you
can create the file above as /etc/alsa.d/rme9652 (with exec bit).  as
other examples, you can load the soundfont on this script for emu10k1
or sbawe.

many distributions use /etc/sysconfig/XXX file for a local
configuration, btw.  in this style, create a file
(e.g. /etc/sysconfig/rme9652) containing the variable definitions such
like:

	HAMMERFALL=0
	CLOCK_MODE=1
	CLOCK_MODE_NAME="master"

and call ". /etc/sysconfig/rme9652" at the beginning of the script.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: possible problems with rc6 aplay

[Paul Davis]

>the standard alsasound init script can call a card-dependent script

that reminds me. the last version of the alsasound script that i saw
did something very dangerous. it seemed to try to install *every*
snd-card module it could find. if you have a system with an ISA bus,
this can prove fatal to the system - many ISA device probes will kill
the machine if the device is not present.

the alsasound script should assume, i think, that alsaconf has been
run, and that only modules listed in /etc/modules.conf or its
equivalent should be loaded.

--p


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: possible problems with rc6 aplay

[Martin Langer]

On Mon, Dec 16, 2002 at 04:04:23AM -0800, Mark Knecht wrote:
> 
>    I'm having an interesting problem with this setup with now that's
> probably based in this area. If I bring up these two systems with the
> main DAW in Linux, and the slave system in Windows everything is fine.
> The DAW controls the frequency via my running jack, but even at first
> boot the two sides lock together just fine. 
> 
>    If I then boot the DAW into Windows, the two sides start making noise
> through the speakers, and if I look at the RME app in Windows on the
> slave machine, the frequency is bouncing around and so is the mode
> saying it's master or slave. The worst part is I get ugly noise out of
> my speakers unless I tell one f the two Windows machines what mode to be
> in.
> 
> On Mon, 2002-12-16 at 02:17, Martin Langer wrote:
> > 
> > But using master clock mode without defining a frequency before isn't
> > plausible for me and defining one master mode for each frequency was only a
> > quick solution by me.
> > 

IMHO this is a design bug of all rme cards. The documents about rme32 and
rme96 where identical in this point. They were talking about one master-mode
and nothing about the frequency. I don't know anything about rme9652 or
hdsp, but the sourcecode looks not very different to the older rme96.

But if you read the datasheet from prodif24 (not supported by alsa) you have
a switch with one slave position and three frequency positions. After
changing my driver from the rme way to this prodif24 way it runs without
this strange frequency problems some people have (I remember
vanDongen/Gilcher talking about a similar problem with his 96/8).

Alsa has copied here the documented rme way, but this seems to be wrong for
me. I have just checked the behaviour of rme32, but I'm very sure that the
bigger ones are working in the same style.

BTW: prodif24 document is on ftp.alsa-project.org


martin






-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: possible problems with rc6 aplay

[Paul Davis]

>IMHO this is a design bug of all rme cards. The documents about rme32 and
>rme96 where identical in this point. They were talking about one master-mode
>and nothing about the frequency. I don't know anything about rme9652 or
>hdsp, but the sourcecode looks not very different to the older rme96.
>
>But if you read the datasheet from prodif24 (not supported by alsa) you have
>a switch with one slave position and three frequency positions. After

the problem here is not setting the card to master mode and not having
a defined frequency - this doesn't happen because there is a defined
default rate (just not well documented). the problem is setting the
rate and it appearing to succeed, even though in fact it has made no
difference to the operation of the card because its slaved to some
external clock.

>Alsa has copied here the documented rme way, but this seems to be wrong for
>me. I have just checked the behaviour of rme32, but I'm very sure that the
>bigger ones are working in the same style.

well, they have a more complex setup:

      * clock mode: AutoSync, Master or Word Clock
      * preferred source for autosync: ADAT1/2/3 or S/PDIF
      * S/PDIF sample rate
      * ADAT sample rate
      * system sample rate (the one the master clock runs at)

so its really not possible to define "the rate" in a straightforward
way. but i see your point.

--p



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

At Mon, 16 Dec 2002 09:29:05 -0500,
Paul Davis wrote:
> 
> >the standard alsasound init script can call a card-dependent script
> 
> that reminds me. the last version of the alsasound script that i saw
> did something very dangerous. it seemed to try to install *every*
> snd-card module it could find. if you have a system with an ISA bus,
> this can prove fatal to the system - many ISA device probes will kill
> the machine if the device is not present.
 
well, you can find that the alsasound script tries to load the modules
aliased as "snd-card-[0-9]", not the all snd-card-* modules.
remember that there is no module named as such.  that means, if such a
module is found, it was certainly configured by some means.


ciao,

Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Paul Davis]

>> that reminds me. the last version of the alsasound script that i saw
>> did something very dangerous. it seemed to try to install *every*
>> snd-card module it could find. if you have a system with an ISA bus,
>> this can prove fatal to the system - many ISA device probes will kill
>> the machine if the device is not present.
> 
>well, you can find that the alsasound script tries to load the modules
>aliased as "snd-card-[0-9]", not the all snd-card-* modules.
>remember that there is no module named as such.  that means, if such a
>module is found, it was certainly configured by some means.

ah. sorry, i missed the -c on modprobe. i take it all back :(

--p


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Mark Knecht]

On Mon, 2002-12-16 at 07:23, Paul Davis wrote:
> >> that reminds me. the last version of the alsasound script that i saw
> >> did something very dangerous. it seemed to try to install *every*
> >> snd-card module it could find. if you have a system with an ISA bus,
> >> this can prove fatal to the system - many ISA device probes will kill
> >> the machine if the device is not present.
> > 
> >well, you can find that the alsasound script tries to load the modules
> >aliased as "snd-card-[0-9]", not the all snd-card-* modules.
> >remember that there is no module named as such.  that means, if such a
> >module is found, it was certainly configured by some means.
> 
> ah. sorry, i missed the -c on modprobe. i take it all back :(
> 
> --p

I wonder if this could have anything to do with a different problem I'm
seeing. I have a HDSP 9652 and a MidiMan 2X2 interface. The HDSP is
installed by alsaconf. The 2X2 is installed usign Fernando's
instructions from the Planet.

When I do a cold boot, the HDSP is always recognized first, and then the
MidiMan comes up as card 2, at least by reading the numbers of the
devices in /dev/snd. However, if I reboot, many times the system makes
the 2X2 card 1 and the HDSP card 2, and that breaks a lot of this
software.

What would cause this to happen and how could I stop it?

I have found that everything seems to work fine if I remember to unplug
the 2X2 when the reboot begins, but sometimes I don't remember and have
to go through one more boot cycle.

Cheers,
Mark



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Paul Davis]

>I wonder if this could have anything to do with a different problem I'm
>seeing. I have a HDSP 9652 and a MidiMan 2X2 interface. The HDSP is
>installed by alsaconf. The 2X2 is installed usign Fernando's
>instructions from the Planet.
>
>When I do a cold boot, the HDSP is always recognized first, and then the
>MidiMan comes up as card 2, at least by reading the numbers of the
>devices in /dev/snd. However, if I reboot, many times the system makes
>the 2X2 card 1 and the HDSP card 2, and that breaks a lot of this
>software.
>
>What would cause this to happen and how could I stop it?

set the snd_index parameter for each module in /etc/modules.conf. this
will force each module to use a particular card number every time.

i think it would something like this:

options snd-hdsp snd_index=0
options snd-usb-foo snd_index=1

i'm sure that takashi or jaroslav will correct me if i got this wrong.

--p


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Mark Knecht]

On Mon, 2002-12-16 at 18:51, Paul Davis wrote:

> 
> i think it would something like this:
> 
> options snd-hdsp snd_index=0
> options snd-usb-foo snd_index=1
> 
> i'm sure that takashi or jaroslav will correct me if i got this wrong.
> 
> --p

Paul,
   This makes perfect sense, and it isn't what I did. (!!)

   The PlanetCCRMA has a Nano-HOWTO on how to install the MidiMan 2X2 by
hand. It's a little USB-based MIDI interface (not a sound card) that is
not recognized by alsaconf, so we do a bit of editing by hand.

   alsaconf sets up modules.conf for the HDSP

# --- BEGIN: Generated by ALSACONF, do not edit. ---
# --- ALSACONF verion 0.9.0 ---
alias char-major-116 snd
alias snd-card-0 snd-hdsp
alias char-major-14 soundcore
alias sound-slot-0 snd-card-0
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
options snd major=116 cards_limit=1 device_mode=0666
options snd-hdsp index=0
# --- END: Generated by ALSACONF, do not edit. ---


We then modify one line in the file to look like this:

options snd major=116 cards_limit=2 device_mode=0666


and we also do the following:

<SNIP from the Planet>
add usb-midi and audio to the /etc/hotplug/blacklist file
So that the OSS audio and usb-midi modules are not automatically loaded
when the device reconnects after the firmware download. Add ``usb-midi''
and ``audio'' in separate lines at the end of the list of blacklisted
modules in that file. 
<End SNIP>

I think, according to your info, that the problem is caused by not
having some sort of 

options snd-midiman index=1

line. That makes sense to me, except that I don't know what to put there
since there actually isn't a driver. The goal is to get the system to
make some devices in /dev/snd. This works fine on a cold boot, but fails
sometimes on a warm boot. (At least I think it does, since sometimes I
get pcmC1D0 when I have no pcmC0D0

Thanks,
Mark



-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

[-- Attachment #1: Type: text/plain, Size: 3755 bytes --]

At 16 Dec 2002 19:46:55 -0800,
Mark Knecht wrote:
> 
> On Mon, 2002-12-16 at 18:51, Paul Davis wrote:
> 
> > 
> > i think it would something like this:
> > 
> > options snd-hdsp snd_index=0
> > options snd-usb-foo snd_index=1
> > 
> > i'm sure that takashi or jaroslav will correct me if i got this wrong.
> > 
> > --p
> 
> Paul,
>    This makes perfect sense, and it isn't what I did. (!!)
> 
>    The PlanetCCRMA has a Nano-HOWTO on how to install the MidiMan 2X2 by
> hand. It's a little USB-based MIDI interface (not a sound card) that is
> not recognized by alsaconf, so we do a bit of editing by hand.
> 
>    alsaconf sets up modules.conf for the HDSP
> 
> # --- BEGIN: Generated by ALSACONF, do not edit. ---
> # --- ALSACONF verion 0.9.0 ---
> alias char-major-116 snd
> alias snd-card-0 snd-hdsp
> alias char-major-14 soundcore
> alias sound-slot-0 snd-card-0
> 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
> options snd major=116 cards_limit=1 device_mode=0666
> options snd-hdsp index=0
> # --- END: Generated by ALSACONF, do not edit. ---
> 
> 
> We then modify one line in the file to look like this:
> 
> options snd major=116 cards_limit=2 device_mode=0666
> 
> 
> and we also do the following:
> 
> <SNIP from the Planet>
> add usb-midi and audio to the /etc/hotplug/blacklist file
> So that the OSS audio and usb-midi modules are not automatically loaded
> when the device reconnects after the firmware download. Add ``usb-midi''
> and ``audio'' in separate lines at the end of the list of blacklisted
> modules in that file. 
> <End SNIP>
> 
> I think, according to your info, that the problem is caused by not
> having some sort of 
> 
> options snd-midiman index=1
> 
> line. That makes sense to me, except that I don't know what to put there
> since there actually isn't a driver. The goal is to get the system to
> make some devices in /dev/snd. This works fine on a cold boot, but fails
> sometimes on a warm boot. (At least I think it does, since sometimes I
> get pcmC1D0 when I have no pcmC0D0

the behavior depends on the order of booting.
if the hotplug service is booted before the alsasound init script,
hotplug will start the snd-usbaudio module, which will be assigned as
the first empty device, i.e. device #0, unless you specify the index
option.  and afterwards, the alsasound script is started, and it
results in the confliction of devices.

setting an index option is one of the solutions.
in this case, the first usb-audio/midi device will be forced to be
assigned to #1.  so, it's safe to start it beforehand.

but, when we take a deeper look at this, we find another problem.
the alsasound init script checks whether the ALSA was already started
by checking the existence of /proc/asound directory.  and, if hotplug
started the usb-audio/midi before alsasound, this directory would be
also created because the alsa core was started without help of
alsasound init script, too.  this leads to the skip of loading of any
other soundcards, because alsasound will quit immediately.

after all, a simple solution for this is to make sure that alsasound
starts before hotplug.  then, even the index option for snd-usbaudio
wouldn't be necessary (in theory).


in the above scenario, anyway, cards_limit must be changed.  and i
think it's a bit annoying.

the attached patch will change the handling of cards_limit option.
with the patch, the alsa won't restrict the number of cards per
cards_limit option, but only limits the auto-probing via kmod.
i.e. you can load more card modules even with cards_limit=1.

i'd like to hear which behavior is preferable.


ciao,

Takashi

[-- Attachment #2: limit-check.dif --]
[-- Type: application/octet-stream, Size: 1133 bytes --]

--- alsa-kernel/core/init.c	12 Jun 2002 10:21:00 -0000	1.9
+++ alsa-kernel/core/init.c	16 Jul 2002 12:11:37 -0000
@@ -67,11 +67,19 @@
 				idx = idx2;
 				break;
 			}
+		if (idx < 0 && snd_ecards_limit < SNDRV_CARDS)
+			/* for dynamically additional devices like hotplug:
+			 * increment the limit if still free slot exists.
+			 */
+			idx = snd_ecards_limit++;
 	} else if (idx < snd_ecards_limit) {
 		if (snd_cards_lock & (1 << idx))
 			idx = -1;	/* invalid */
-	}
-	if (idx < 0 || idx >= snd_ecards_limit) {
+	} else if (idx < SNDRV_CARDS)
+		snd_ecards_limit = idx + 1; /* increase the limit */
+	else
+		idx = -1;
+	if (idx < 0) {
 		write_unlock(&snd_card_rwlock);
 		if (idx >= snd_ecards_limit)
 			snd_printk(KERN_ERR "card %i is out of range (0-%i)\n", idx, snd_ecards_limit-1);
--- alsa-kernel/core/sound.c	23 May 2002 08:26:29 -0000	1.14
+++ alsa-kernel/core/sound.c	16 Jul 2002 12:13:03 -0000
@@ -81,7 +81,7 @@
 
 	if (snd_cards[card] != NULL)
 		return;
-	if (card < 0 || card >= snd_ecards_limit)
+	if (card < 0 || card >= snd_cards_limit)
 		return;
 	sprintf(str, "snd-card-%i", card);
 	request_module(str);

clock mode problem [was: possible problems with rc6 aplay]

[Martin Langer]

On Mon, Dec 16, 2002 at 09:51:34AM -0500, Paul Davis wrote:
> 
> >Alsa has copied here the documented rme way, but this seems to be wrong for
> >me. I have just checked the behaviour of rme32, but I'm very sure that the
> >bigger ones are working in the same style.
> 
> well, they have a more complex setup:
> 
>       * clock mode: AutoSync, Master or Word Clock
>       * preferred source for autosync: ADAT1/2/3 or S/PDIF
>       * S/PDIF sample rate
>       * ADAT sample rate
>       * system sample rate (the one the master clock runs at)
> 
> so its really not possible to define "the rate" in a straightforward
> way. but i see your point.
> 

Hmm, it's more complex, but it looks not so different. 

So, I will show you another corner of this problem.

Like every rme card you have to set the rate of your output with 2 or 3
bits. The funny thing is, they never talked about the zero position. I've
tried out this with my rme32 and it is the slave clock position. Let's call
it "switch off the internal master clock".

The datasheet is just talking about one specific Master Clock Bit and not
about zeroing the sample rate bits, if you want to use slave mode. Right?

A practical experiment: If you are in slave clock mode and you are changing
the input sample rate, the output doesn't follow automatically. But if
you've set the sample rate bits for output to 0-0 before, the output rate
will change on each input change (like it should be in a perfect slave mode).

And if you want to change from slave to master clock you have to set a
sample rate different from 0-0 again. So it is only possible to switch
between this clockmodes if you are setting the sample rate and the result is
a list of master modes with sample rate dependency.

output rate bits      Master/Slave bit	Mode    	    	 
0-0  	    	      Slave	   	Slave mode
0-1		      Master		Master mode (freq. #1)
1-0		      Master		Master mode (freq. #2)
...

Everything is without warranty, but I'm very sure that this is typical for
all other rme cards: rme96, rme9652, hdsp. But I've no possibility to check
it.


martin


-- 
"2b|!2b"


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Fernando Pablo Lopez-Lezcano]

On Tue, 2002-12-17 at 03:06, Takashi Iwai wrote:
> At 16 Dec 2002 19:46:55 -0800,
> Mark Knecht wrote:
> > On Mon, 2002-12-16 at 18:51, Paul Davis wrote:
> > > i think it would something like this:
> > > 
> > > options snd-hdsp snd_index=0
> > > options snd-usb-foo snd_index=1
> > > 
> > > i'm sure that takashi or jaroslav will correct me if i got this wrong.
> > 
> >    This makes perfect sense, and it isn't what I did. (!!)
> > 
> >    The PlanetCCRMA has a Nano-HOWTO on how to install the MidiMan 2X2 by
> > hand. It's a little USB-based MIDI interface (not a sound card) that is
> > not recognized by alsaconf, so we do a bit of editing by hand.
> 
> the behavior depends on the order of booting.
> if the hotplug service is booted before the alsasound init script,
> hotplug will start the snd-usbaudio module, which will be assigned as
> the first empty device, i.e. device #0, unless you specify the index
> option.  and afterwards, the alsasound script is started, and it
> results in the confliction of devices.
> 
> setting an index option is one of the solutions.
> in this case, the first usb-audio/midi device will be forced to be
> assigned to #1.  so, it's safe to start it beforehand.
> 
> but, when we take a deeper look at this, we find another problem.
> the alsasound init script checks whether the ALSA was already started
> by checking the existence of /proc/asound directory.  and, if hotplug
> started the usb-audio/midi before alsasound, this directory would be
> also created because the alsa core was started without help of
> alsasound init script, too.  this leads to the skip of loading of any
> other soundcards, because alsasound will quit immediately.
> 
> after all, a simple solution for this is to make sure that alsasound
> starts before hotplug.  then, even the index option for snd-usbaudio
> wouldn't be necessary (in theory).

I think that in RedHat hotplug is not started as a service so we cannot
make sure that alsasound starts first (at least not easily - I have to
check again on the startup scripts to see what is done and when). 

It would be better to make the alsasound script more robust (and
independent of the startup order) and able to deal with partially loaded
modules, so instead of just checking for the /proc/asound directory it
would actually see what modules are already loaded and only load those
that are not. It does not look too easy, it seems that /proc/asound does
not provide a list of loaded modules (rather a list of cards that are
not associated with module names). 

> in the above scenario, anyway, cards_limit must be changed.  and i
> think it's a bit annoying.
> 
> the attached patch will change the handling of cards_limit option.
> with the patch, the alsa won't restrict the number of cards per
> cards_limit option, but only limits the auto-probing via kmod.
> i.e. you can load more card modules even with cards_limit=1.

That sounds reasonable. 
-- Fernando




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

At 17 Dec 2002 11:36:10 -0800,
Fernando Pablo Lopez-Lezcano wrote:
> 
> On Tue, 2002-12-17 at 03:06, Takashi Iwai wrote:
> > At 16 Dec 2002 19:46:55 -0800,
> > Mark Knecht wrote:
> > > On Mon, 2002-12-16 at 18:51, Paul Davis wrote:
> > > > i think it would something like this:
> > > > 
> > > > options snd-hdsp snd_index=0
> > > > options snd-usb-foo snd_index=1
> > > > 
> > > > i'm sure that takashi or jaroslav will correct me if i got this wrong.
> > > 
> > >    This makes perfect sense, and it isn't what I did. (!!)
> > > 
> > >    The PlanetCCRMA has a Nano-HOWTO on how to install the MidiMan 2X2 by
> > > hand. It's a little USB-based MIDI interface (not a sound card) that is
> > > not recognized by alsaconf, so we do a bit of editing by hand.
> > 
> > the behavior depends on the order of booting.
> > if the hotplug service is booted before the alsasound init script,
> > hotplug will start the snd-usbaudio module, which will be assigned as
> > the first empty device, i.e. device #0, unless you specify the index
> > option.  and afterwards, the alsasound script is started, and it
> > results in the confliction of devices.
> > 
> > setting an index option is one of the solutions.
> > in this case, the first usb-audio/midi device will be forced to be
> > assigned to #1.  so, it's safe to start it beforehand.
> > 
> > but, when we take a deeper look at this, we find another problem.
> > the alsasound init script checks whether the ALSA was already started
> > by checking the existence of /proc/asound directory.  and, if hotplug
> > started the usb-audio/midi before alsasound, this directory would be
> > also created because the alsa core was started without help of
> > alsasound init script, too.  this leads to the skip of loading of any
> > other soundcards, because alsasound will quit immediately.
> > 
> > after all, a simple solution for this is to make sure that alsasound
> > starts before hotplug.  then, even the index option for snd-usbaudio
> > wouldn't be necessary (in theory).
> 
> I think that in RedHat hotplug is not started as a service so we cannot
> make sure that alsasound starts first (at least not easily - I have to
> check again on the startup scripts to see what is done and when). 
 
hmm, then it's difficult to assume the order...
in most cases, hotplug is started at the fairly early stage of boot
sequences, because it supports also the fundamental devices such like
network.

> It would be better to make the alsasound script more robust (and
> independent of the startup order) and able to deal with partially loaded
> modules, so instead of just checking for the /proc/asound directory it
> would actually see what modules are already loaded and only load those
> that are not. It does not look too easy, it seems that /proc/asound does
> not provide a list of loaded modules (rather a list of cards that are
> not associated with module names). 
 
agreed.  a scenario i can imagine now is that the script just takes a
look at /proc/asound/cards and checks the numbers at the first column.
this should correspond to the card indices which have been already
loaded.  then the script will try to load the modules snd-card-X but
skip the numbers listed in the above...
i'll try to rewrite as this way.


> > in the above scenario, anyway, cards_limit must be changed.  and i
> > think it's a bit annoying.
> > 
> > the attached patch will change the handling of cards_limit option.
> > with the patch, the alsa won't restrict the number of cards per
> > cards_limit option, but only limits the auto-probing via kmod.
> > i.e. you can load more card modules even with cards_limit=1.
> 
> That sounds reasonable. 

fine, does anybody see a drawback?


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

At Wed, 18 Dec 2002 11:46:45 +0100,
I wrote:
> 
> > It would be better to make the alsasound script more robust (and
> > independent of the startup order) and able to deal with partially loaded
> > modules, so instead of just checking for the /proc/asound directory it
> > would actually see what modules are already loaded and only load those
> > that are not. It does not look too easy, it seems that /proc/asound does
> > not provide a list of loaded modules (rather a list of cards that are
> > not associated with module names). 
>  
> agreed.  a scenario i can imagine now is that the script just takes a
> look at /proc/asound/cards and checks the numbers at the first column.
> this should correspond to the card indices which have been already
> loaded.  then the script will try to load the modules snd-card-X but
> skip the numbers listed in the above...
> i'll try to rewrite as this way.

after reconsideration: it would be much simpler to create a new proc
file which shows the modules already loaded.


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Mark Knecht]

On Wed, 2002-12-18 at 03:17, Takashi Iwai wrote:
> At Wed, 18 Dec 2002 11:46:45 +0100,
> I wrote:
> > 
> > > It would be better to make the alsasound script more robust (and
> > > independent of the startup order) and able to deal with partially loaded
> > > modules, so instead of just checking for the /proc/asound directory it
> > > would actually see what modules are already loaded and only load those
> > > that are not. It does not look too easy, it seems that /proc/asound does
> > > not provide a list of loaded modules (rather a list of cards that are
> > > not associated with module names). 
> >  
> > agreed.  a scenario i can imagine now is that the script just takes a
> > look at /proc/asound/cards and checks the numbers at the first column.
> > this should correspond to the card indices which have been already
> > loaded.  then the script will try to load the modules snd-card-X but
> > skip the numbers listed in the above...
> > i'll try to rewrite as this way.
> 
> after reconsideration: it would be much simpler to create a new proc
> file which shows the modules already loaded.
> 
I was wondering what would happen in this process if someone had two r
three identical USB devices, like the MidiMan 2X2? OR also two identical
cards like the RME HDSP 9652?

It is important that the system recognize the same hardware as the same
sound device every time the machine booted, and whether the machine is
warm or cold booted. 

The name I'm seeing linked in /dev/sound are possibly a bit too generic,
being just '2X2' and 'DSP'.

Just a thought.




-------------------------------------------------------
This sf.net email is sponsored by:
With Great Power, Comes Great Responsibility 
Learn to use your power at OSDN's High Performance Computing Channel
http://hpc.devchannel.org/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

At 18 Dec 2002 05:11:36 -0800,
Mark Knecht wrote:
> 
> On Wed, 2002-12-18 at 03:17, Takashi Iwai wrote:
> > At Wed, 18 Dec 2002 11:46:45 +0100,
> > I wrote:
> > > 
> > > > It would be better to make the alsasound script more robust (and
> > > > independent of the startup order) and able to deal with partially loaded
> > > > modules, so instead of just checking for the /proc/asound directory it
> > > > would actually see what modules are already loaded and only load those
> > > > that are not. It does not look too easy, it seems that /proc/asound does
> > > > not provide a list of loaded modules (rather a list of cards that are
> > > > not associated with module names). 
> > >  
> > > agreed.  a scenario i can imagine now is that the script just takes a
> > > look at /proc/asound/cards and checks the numbers at the first column.
> > > this should correspond to the card indices which have been already
> > > loaded.  then the script will try to load the modules snd-card-X but
> > > skip the numbers listed in the above...
> > > i'll try to rewrite as this way.
> > 
> > after reconsideration: it would be much simpler to create a new proc
> > file which shows the modules already loaded.
> > 
> I was wondering what would happen in this process if someone had two r
> three identical USB devices, like the MidiMan 2X2? OR also two identical
> cards like the RME HDSP 9652?
 
when a module is loaded and two or more identical (or supported)
devices are connected, the module will initialize the all such devices
at once.

for multiple devices, you can specify the options separated by commas,

	options snd-hdsp index=1,2,3 id="hdsp1","hdsp2","hdsp3"

if there is no index option given for a device, as mentioned before,
an empty slot is probed from the index 0.  thus, if you don't set any
index options for all modules, that's fine, except for that the order
of devices is not guaranteed.  (cards_limit option must be enough
large, or you need to apply my patch.)
for keeping the order of devices, giving the index option for each
device would be better.


> It is important that the system recognize the same hardware as the same
> sound device every time the machine booted, and whether the machine is
> warm or cold booted. 
 
in the case of usb, it's not 100% sure, because it's anyway
hotpluggable.  but usually the order of probing is identical, so it's
ok.


Takashi


-------------------------------------------------------
This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
Time is running out!  Thinkgeek.com has the coolest gifts for
your favorite geek.   Let your fingers do the typing.   Visit Now.
T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Clemens Ladisch]

Takashi Iwai wrote:
> Mark Knecht wrote:
> > I was wondering what would happen in this process if someone had two r
> > three identical USB devices, like the MidiMan 2X2? OR also two identical
> > cards like the RME HDSP 9652?
>
> when a module is loaded and two or more identical (or supported)
> devices are connected, the module will initialize the all such devices
> at once.
>
> for multiple devices, you can specify the options separated by commas,
>
> > It is important that the system recognize the same hardware as the same
> > sound device every time the machine booted, and whether the machine is
> > warm or cold booted.
>
> in the case of usb, it's not 100% sure, because it's anyway
> hotpluggable.  but usually the order of probing is identical, so it's
> ok.

It is possible to force USB devices to a specific index with the vid/pid
parameters for the vendor/product id, even when hotplugging.
However, this won't work when you hotplug two identical devices (with the
same product id).


Clemens



-------------------------------------------------------
This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
Time is running out!  Thinkgeek.com has the coolest gifts for
your favorite geek.   Let your fingers do the typing.   Visit Now.
T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Pedro Lopez-Cabanillas]

On Friday 20 December 2002 21:09, Clemens Ladisch wrote:
> Takashi Iwai wrote:
> > Mark Knecht wrote:
> > > I was wondering what would happen in this process if someone had two r
> > > three identical USB devices, like the MidiMan 2X2? OR also two
> > > identical cards like the RME HDSP 9652?
> >
> > when a module is loaded and two or more identical (or supported)
> > devices are connected, the module will initialize the all such devices
> > at once.
> >
> > for multiple devices, you can specify the options separated by commas,
> >
> > > It is important that the system recognize the same hardware as the same
> > > sound device every time the machine booted, and whether the machine is
> > > warm or cold booted.
> >
> > in the case of usb, it's not 100% sure, because it's anyway
> > hotpluggable.  but usually the order of probing is identical, so it's
> > ok.

The probing order is the same if you plug everytime the same device at the 
same USB bus/port. Hotplug agent also receives an environment variable,  
DEVICE=/proc/bus/usb/001/002 or something like this, being the last numbers 
the USB bus and device numbers.

> It is possible to force USB devices to a specific index with the vid/pid
> parameters for the vendor/product id, even when hotplugging.
> However, this won't work when you hotplug two identical devices (with the
> same product id).

The vid/pid parameters work well for me, as i have two USB MIDI devices from  
different vendors. It works regarding the plug order, or the USB port used. 
Perhaps another parameter like usbdev=001/002 or something else could be 
useful in case that someone has several identical devices?

Clemens, I remember that /proc/asound/cards returned this bus/device  
information for USB MIDI devices some time ago (rc3?), like it does for my SB 
128 PCI.

Regards,
Pedro

-- 
ALSA Library Bindings for Pascal
http://alsapas.alturl.com



-------------------------------------------------------
This SF.NET email is sponsored by:  The Best Geek Holiday Gifts!
Time is running out!  Thinkgeek.com has the coolest gifts for
your favorite geek.   Let your fingers do the typing.   Visit Now.
T H I N K G E E K . C O M        http://www.thinkgeek.com/sf/

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Takashi Iwai]

At Fri, 20 Dec 2002 23:53:13 +0100,
Pedro Lopez-Cabanillas wrote:
> 
> Clemens, I remember that /proc/asound/cards returned this bus/device  
> information for USB MIDI devices some time ago (rc3?), like it does for my SB 
> 128 PCI.

it would be nice to provide a new generic proc file which shows the
low-level hardware information as the card number, the module name and
the PCI/ISA-PnP/USB/PCMCIA IDs like:

0 snd-ens1371 0x0123 0xABCD
1 snd-usb-audio 0xXXXX 0xYYYY


Takashi


-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf

Re: alsasound init script (Re: possible problems with rc6 aplay )

[Patrick Shirkey]

Takashi Iwai wrote:
> At Fri, 20 Dec 2002 23:53:13 +0100,
> Pedro Lopez-Cabanillas wrote:
> 
>>Clemens, I remember that /proc/asound/cards returned this bus/device  
>>information for USB MIDI devices some time ago (rc3?), like it does for my SB 
>>128 PCI.
> 
> 
> it would be nice to provide a new generic proc file which shows the
> low-level hardware information as the card number, the module name and
> the PCI/ISA-PnP/USB/PCMCIA IDs like:
> 
> 0 snd-ens1371 0x0123 0xABCD
> 1 snd-usb-audio 0xXXXX 0xYYYY
> 

Could you add to that the irq number?



-- 
Patrick Shirkey - Boost Hardware Ltd.
For the discerning hardware connoisseur
Http://www.boosthardware.com
Http://www.djcj.org - The Linux Audio Users guide
========================================

Being on stage with the band in front of crowds shouting, "Get off! No! 
We want normal music!", I think that was more like acting than anything 
I've ever done.

Goldie, 8 Nov, 2002
The Scotsman



-------------------------------------------------------
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf