Re: alsasound init script (Re: [Alsa-devel] possible problems with rc6 aplay )
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 0x 0x Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: alsasound init script (Re: [Alsa-devel] possible problems with rc6 aplay )
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 Mhttp://www.thinkgeek.com/sf/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: alsasound init script (Re: [Alsa-devel] possible problems with rc6 aplay )
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 Mhttp://www.thinkgeek.com/sf/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: alsasound init script (Re: [Alsa-devel] possible problems with rc6 aplay )
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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: alsasound init script (Re: [Alsa-devel] possible problems with rc6 aplay )
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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
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.# " 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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: alsasound init script (Re: [Alsa-devel] possible problems with rc6 aplay )
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: > > > 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. > > > 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 limit-check.dif Description: Binary data
Re: alsasound init script (Re: [Alsa-devel] possible problems with rc6 aplay )
>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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
>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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
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/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: alsasound init script (Re: [Alsa-devel] possible problems with rc6 aplay )
>> 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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
alsasound init script (Re: [Alsa-devel] possible problems with rc6 aplay )
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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
>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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
>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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
>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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
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 > > > [EMAIL PROTECTED] > > > 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 >
Re: [Alsa-devel] possible problems with rc6 aplay
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 > > [EMAIL PROTECTED] > > 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 > [EMAIL PROTECTED] > 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/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
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 > [EMAIL PROTECTED] > 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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
>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 [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] possible problems with rc6 aplay
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
> [EMAIL PROTECTED]
> 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
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] possible problems with rc6 aplay
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
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
