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: possible problems with rc6 aplay

[Mark Knecht]

This sounds like a fine solution Paul. I'll give it a shot.

Thanks!

On Mon, 2002-12-16 at 05:49, 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.
> 
> 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

[patrick reardon]

paul davis wrote:
>
> 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.

yes, thnx, it's much clearer now.  my converter is external with no rate switches and from
the manual i just discovered it always operates at 48000 (Alesis AI-3).  i'm still
uncertain how to change the card's configuration though.  "alsactl" doesn't seem to
provide an obvious way to do this (looking at the man page).  but my asound.state file has

--------------------snip--------------------
        control.8 {
                comment.access 'read write'
                comment.type ENUMERATED
                comment.item.0 'IEC958 In'
                comment.item.1 'ADAT1 In'
                comment.item.2 'ADAT2 In'
                iface PCM
                name 'Preferred Sync Source'
                value 'ADAT1 In'
	}
--------------------snip--------------------

do i just edit this by hand, changing value 'ADAT1 In' to value 'master', or ........ ??  

patrick



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.
> 
> --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]

Patrick,
   I believe the AI-3 operates at 48K if it is not receiving a clock via
it's ADAT input. If the ADAT input is applied and provides 44.1K, then
it is my understanding that the AI-3 operates at 44.1K.

Mark

On Mon, 2002-12-16 at 14:53, patrick reardon wrote:
> 
> yes, thnx, it's much clearer now.  my converter is external with no rate switches and from
> the manual i just discovered it always operates at 48000 (Alesis AI-3).  i'm still
> uncertain how to change the card's configuration though.  "alsactl" doesn't seem to
> provide an obvious way to do this (looking at the man page).  but my asound.state file has




-------------------------------------------------------
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]

>yes, thnx, it's much clearer now.  my converter is external with no
>rate switches and from the manual i just discovered it always
>operates at 48000 (Alesis AI-3).  i'm s till uncertain how to change
>the card's configuration though.  "alsactl" doesn't se em to provide
>an obvious way to do this (looking at the man page).  but my
>asound.state file has [ ... ]

what do you want to change it to?

--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

[patrick reardon]

Paul Davis wrote:
> 
> >yes, thnx, it's much clearer now.  my converter is external with no
> >rate switches and from the manual i just discovered it always
> >operates at 48000 (Alesis AI-3).  i'm s till uncertain how to change
> >the card's configuration though.  "alsactl" doesn't seem to provide
> >an obvious way to do this (looking at the man page).  but my
> >asound.state file has [ ... ]
> 
> what do you want to change it to?
> 
> --p

thanks to all the posts about my problem, i inferred that setting the "Preferred Sync
Source" of the hammerfall to Master would be one way to solve the problem, and possibly
solve some others too, like third party WAV files at 22050 that play back way too fast
regardless of the --rate=# option given to "aplay".  (in my setup, play back output runs
through the converter to an analog mixer and then on to the speakers.)  

i just looked again at the asound.state file with a fresh pair of eyes, and apparently the
only allowable values for Preferred Sync Source are IEC958, ADAT1, and ADAT2.  Sync Mode
seems to be the only control that has Master as an allowable value,  (this based on my
guess that lines like "comment.item.# <string>" list the allowable values for the
parameter.)  

on the other hand, i could leave ADAT1 as the preferred sync source and give "arecord" the
option -f dat to make 48000 WAV files, then resample to 44100 when i want to burn a CD. 
maybe this approach wouldn't confuse Alsa into writing incorrect headers, but i don't know
if it would sacrifice audio quality on the resulting CD (as opposed to just recording
everything at 44100).  

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/

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/