Re: [Alsa-devel] hdsp driver and tools update
On Sat, 2003-11-01 at 03:19, Thomas Charbonnel wrote: > Hi, > > I apologize for having been so silent the last few weeks, I was in the > process of moving from Lyon, France to Berlin, Germany. This is now done, > and I resumed my work on the hdsp driver and tools. > Latest patches and tools can be found here : > http://www.undata.org/~thomas/ > Mojor changes include support for hdsp 9632 cards and bugfixes for hdsp > 9652 cards. > Hdspconf and hdspmixer now support 96xx cards, though this needs testing > as I do not have the hardware. > > People testing this should remove their asound.state file from the way > because the number or numid of ctls may have change. > > Takashi, I noticed that though it's been in cvs for some time now, > hdspconf is still not included in alsa-tools releases, is there a reason > for this ? > > Thomas > Hi Thomas, Welcome back, and thanks for all the efforts. Your work has been so helpful in getting my system running. It wouldn't be running without you. I really look forward to getting all of this into CVS and no longer having to do patches! Thanks again. Cheers, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] After warm boot Alsa not detecting sound card
Hi, This is not a new problem on my system, but I wanted to get up to date with Alsa before I presented it here. If I do a cold boot then Alsa is correctly installed and both my HDSP 9652 and my MidiSport 2x2 are detected and work fine. However, after a warm boot Alsa never installs for the HDSP 9652. A BIT IMPROVEMENT with 0.9.8 is that Alsa will now load if I stop and start Alsa by hand after the warm boot, so thanks for that! I used to have to completely power down with 0.9.6, so this is a big improvement! However, I'd like to get this fixed so that even these by-hand steps are not required. After a warm boot the card is visible as a PCI device, but it isn't given an interrupt and the drivers aren't loaded: Wizard asound # lspci 00:0e.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP (rev 65) Wizard asound # Wizard asound # cat /proc/interrupts CPU0 0: 86720IO-APIC-edge timer 1: 1271IO-APIC-edge keyboard 2: 0 XT-PIC cascade 8: 2IO-APIC-edge rtc 9: 0 IO-APIC-level acpi 12: 12786IO-APIC-edge PS/2 Mouse 14: 6276IO-APIC-edge ide0 15: 5IO-APIC-edge ide1 16: 27066 IO-APIC-level ohci1394, [EMAIL PROTECTED]:1:0:0 18: 62 IO-APIC-level eth0 21: 1332 IO-APIC-level usb-uhci, usb-uhci, usb-uhci NMI: 0 LOC: 86667 ERR: 0 MIS: 0 Wizard asound # bash-2.05b$ su - Password: Wizard root # lsmod Module Size Used byNot tainted radeon103400 1 usb-midi 17180 0 (unused) audio 41400 0 (unused) snd-usb-audio 46336 0 snd-rawmidi15072 0 [snd-usb-audio] snd-pcm64804 0 [snd-usb-audio] snd-page-alloc 6676 0 [snd-pcm] hid15108 1 snd-seq39408 0 (unused) snd-timer 15876 0 [snd-pcm snd-seq] snd-seq-device 4416 0 [snd-rawmidi snd-seq] snd35428 0 [snd-usb-audio snd-rawmidi snd-pcm snd-seq snd-timer snd-seq-device] sbp2 17984 0 (unused) raw1394 8028 0 (unused) ohci1394 18196 0 (unused) ieee1394 35280 0 [sbp2 raw1394 ohci1394] Wizard root # Wizard asound # pwd /proc/asound Wizard asound # more version Advanced Linux Sound Architecture Driver Version 0.9.8. Compiled on Nov 2 2003 for kernel 2.4.20-gentoo-r7 with versioned symbols. Wizard asound # I can at this point stop and restart Alsa and everything works: Wizard root # lsmod Module Size Used byNot tainted radeon103400 1 usb-midi 17180 0 (unused) audio 41400 0 (unused) hid15108 1 sbp2 17984 0 (unused) raw1394 8028 0 (unused) ohci1394 18196 0 (unused) ieee1394 35280 0 [sbp2 raw1394 ohci1394] Wizard root # /etc/init.d/alsasound start * Loading ALSA drivers... * Loading: snd-seq-oss * Loading: snd-pcm-oss * Loading: snd-mixer-oss * Loading: snd-hdsp * Loading: snd-usb-audio * Loading: snd-seq-midi * Loading: snd-seq-oss * Running card-dependent scripts * Restoring Mixer Levels [ ok ] Wizard root # lsmod Module Size Used byNot tainted snd-pcm-oss39492 0 (unused) snd-mixer-oss 13648 0 [snd-pcm-oss] snd-usb-audio 46336 0 snd-seq-midi4096 0 (autoclean) (unused) snd-hdsp 39204 0 snd-pcm64804 0 (autoclean) [snd-pcm-oss snd-usb-audio snd-hdsp] snd-rawmidi15072 0 (autoclean) [snd-usb-audio snd-seq-midi snd-hdsp] snd-page-alloc 6676 0 (autoclean) [snd-hdsp snd-pcm] snd-hwdep 5344 0 (autoclean) [snd-hdsp] snd-seq-oss30368 0 (unused) snd-seq-midi-event 3840 0 [snd-seq-midi snd-seq-oss] snd-seq39408 2 [snd-seq-midi snd-seq-oss snd-seq-midi-event] snd-timer 15876 0 [snd-pcm snd-seq] snd-seq-device 4416 0 [snd-seq-midi snd-rawmidi snd-seq-oss snd-seq] snd35428 0 [snd-pcm-oss snd-mixer-oss snd-usb-audio snd-seq-midi snd-hdsp snd-pcm snd-rawmidi snd-hwdep snd-seq-oss snd-seq-midi-event snd-seq snd-timer snd-seq-device] radeon103400 1 usb-midi 17180 0 (unused) audio 41400 0 (unused) hid15108 1 sbp2 17984 0 (unused) raw1394 8028 0 (unused) ohci1394 18196 0 (unused) ieee1394 35280 0 [sbp2 raw1394 ohci1394] Wizard root # Wizard root # cat /proc/interrupts CPU0 0: 115711IO-APIC-edge timer 1:
Re: [Alsa-devel] After warm boot Alsa not detecting sound card
Fernando, Thanks for the response. I have blacklisted the usb-midi and audio drivers and they no longer load. as expected. I discovered this afternoon that I have too much stuff in modules.conf I think. (Actually in /etc/modules.d/alsa) # OSS/Free portion - card #1 (HDSP9652) 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 # OSS/Free portion - card #2 (MidiSport 2x2) alias sound-service-1-0 snd-mixer-oss alias sound-service-1-1 snd-seq-oss alias sound-service-1-3 snd-pcm-oss alias sound-service-1-8 snd-seq-oss alias sound-service-1-12 snd-pcm-oss alias /dev/mixer snd-mixer-oss alias /dev/dsp snd-pcm-oss alias /dev/midi snd-seq-oss Shouldn't I remove some of the services for card #2? (The MidiSport) The PlanetCCRMA Nano Config guide doesn't seem to show which of these 5 aliases should be used. (If any!) Can you help? I'll try removing the mixer and pcm-oss ones, and I'll try keeping the seq-oss ones, however all of that is just OSS support, correct? Running Alsa apps, do I care at all about OSS support for the MidiSport? I'm thinking no, and that maybe all 5 lines can be removed? On Mon, 2003-11-03 at 13:04, Fernando Pablo Lopez-Lezcano wrote: > The following two are the oss usb modules, you should blacklist them in > /etc/hotplug/blacklist so that only the alsa modules are loaded. > > > usb-midi 17180 0 (unused) > > audio 41400 0 (unused) > > This is, I think, a problem with the stock alsasound script. It does not take into > account that other stuff may start alsa subsystems before the alsasound script > runs. > > In this case hotplug loads the alsa usb driver. A while later alsasound is > executed but it tests for /proc/asound to determine if it is "already running", > that test is true and the rest of the alsa modules are not started. > > If this is (as I suspect) in your Gentoo box you could try copying the hacks > I made to the Planet CCRMA alsasound script so that it loads anything that has > not been loaded so far. That should fix the problem. > I will take a close look at that script on my Planet box soon and see if I can scope out what you did. Thanks for the pointer. With best regards, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] After warm boot Alsa not detecting sound card
On Mon, 2003-11-03 at 13:04, Fernando Pablo Lopez-Lezcano wrote: > It _is_ strange that the alsa usb modules are also loaded... It seems to be used when I make MIDI connections with aconnect to make MIDI connections. The usage count jumps up. I looked at your alsasound script (from /etc/init.d) and the Gentoo one. They are *very* different. I think for the short term I'll just stop and start alsa by hand, maybe in a sudo script or something, until I get some time to really think about this stuff. Or possibly you're comments will start a discussion that leads to a better script. Why wouldn't this be better for Alsa to be in CVS? Thanks! Cheers, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] After warm boot Alsa not detecting sound card
On Tue, 2003-11-04 at 01:41, Frank Barknecht wrote: > Hallo, > Mark Knecht hat gesagt: // Mark Knecht wrote: > > > # OSS/Free portion - card #1 (HDSP9652) > > 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 > > > > # OSS/Free portion - card #2 (MidiSport 2x2) > > alias sound-service-1-0 snd-mixer-oss > > alias sound-service-1-1 snd-seq-oss > > alias sound-service-1-3 snd-pcm-oss > > alias sound-service-1-8 snd-seq-oss > > alias sound-service-1-12 snd-pcm-oss > > You don't need to define snd-seq-oss for the second card, as there is > only one sequencer device anyway, and that includes both cards. You > probably also don't need snd-mixer and snd-oss for the 2x2, because > the Midisport does no audio, or does it? You are exactly correct. I removed those last evening. It doesn't seem to change what drivers get loaded at all, and it doesn't fix my problem. I still cannot do a warm boot and get Alsa to load correctly. Have the developers considered Fernando's comments about the startup scripts before? I don't know, but they seem to the point. Anyway, with all 5 lines removed I seem to get the same things loaded as per lsmod's output, and I seem to have the same problems, so this is not the answer. None the less, I'm happy to try and use Alsa the way the developers intended it. Thanks, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Pops at start of song
Steve,
You're the first person I can remember to report something very similar
to what I'm dealing with every day. I get a huge loud cracking noise at the
start of any audio operation that is not vanilla Alsa - i.e. - anything
accessing OSS I think. In my case I think it's hardware based, but I'm not
sure. This happens only on my HDSP 9652 system. I have two other systems,
one using an onboard NForce audio device, and the other using an RME
Hammerfall Light, that act correctly.
With the RME products we have the hdspconf application which shows the
sync frequency of the card. I normally run at 44.1K, but if I open hdspconf
and watch the card's frequency, it tells me that the card becomes unlocked
and changes sample rates when the noise happens. This happens when starting
any app that uses OSS (I think) like gxine, or xmms, or most games, or
browsing web pages. It does not happen when starting a native Alsa
application like alsaplayer.
Does this sound at all like what you're experiencing?
- Mark
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] Behalf Of Steve
> deRosier
> Sent: Wednesday, November 19, 2003 2:15 PM
> To: [EMAIL PROTECTED]
> Subject: [Alsa-devel] Pops at start of song
>
>
> All,
>
> We're having a problem with some of our audio applications. When a song
> starts playing we will often hear a loud pop out of the speakers before
> it plays audio. It seems dependent upon where we stoped and the specfic
> content of the last song, if we hit our "stop control" and abort in the
> middle of the song it may pop uppon restarting or starting a new song.
>
> One of our engrs found if he fills the entire buffer with zeros before
> quitting the program, on the next start it won't pop (though that moves
> the pop to the end of the previous due to a disconnect/jump in the
> created waveform). Unless this is a hardware issue, this doesn't seem
> to be the right solution to me. So:
>
> * What are things that we can do in our program using the alsa pcm
> functions to eliminate this? Maybe a specific function we need to call
> or a particular sequence?
> * Or, is this something inherent in hardware and other than filling with
> zeros before we quit there's nothing we can do?
>
> I figure some of you have encountered this before, so maybe there's some
> ideas out there?
>
> If you're wondering what we do when a "stop" command comes in: pretty
> much nothing. Basically my "ALSASender" routine ends and calls:
> void CDSP::ClosePCM( void )
> {
>// some other bookkeeping goes here
>
>snd_pcm_close( hPCM );
>
>if( mPCMStatus )
>{
> snd_pcm_status_free( mPCMStatus );
> mPCMStatus = NULL;
>}
>
>// Non-alsa related cleanup goes here
> }
>
> Also, note that we do get the same pops with using aplay.
>
> Thanks,
> - Steve
>
> PS Takashi -> I haven't given up on my serial driver patch, I was
> working on it when I got interupted with something else, it should be on
> its way soon; thanks for your help.
>
>
>
> ---
> This SF.net email is sponsored by: SF.net Giveback Program.
> Does SourceForge.net help you be more productive? Does it
> help you create better code? SHARE THE LOVE, and help us help
> YOU! Click Here: http://sourceforge.net/donate/
> ___
> Alsa-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
>
>
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Pops at start of song
Jaroslav, I certainly want you to know that I have always sensed your commitment to solving these problems and making Alsa better. I also understand that it's terribly difficult for you to debug these things at a distance with a putz like me who isn't a developer, and apparently the only person having this problem. Please tell me how specifically what you want in the s/pdif recording. Would you like me to record the HDSP s/pdif audio output on my Pro Tools box and see if the noise is there? Easy to do and I'll do it this evening. Would having an account and root password on this system help you in any way? If so, we can arrange that. This is how Thomas and I helped move the HDSP 9652 driver forward. He programmed. I looked and listened. Please remember that this problem does not occur when I use Alsa applications, which should help us focus in on the cause. It happens only when using applications that are not specifically Alsa, so I guess that means they are using OSS. I have tried things like plughw and other stuff in my .asoundrc file but none of that has helped this problem. (Of course, I do not understand the .asoundrc file language, so it's probably wrong anyway.) In thinking about this problem, I have come to wonder if the problem is related to the type of A/D-D/A hardware that I have attached to ADAT2, and which is part of my output signal chain. The Alesis AI-3 is a simple 8-in/8-out unit. It works very well, but it has one particular quirk, if you will, in that it always wants to run at 48KHz unless it is given a sync signal via its ADAT input at a different frequency. I run at 44.1K, and my sense is that the AI-3 is jumping to 48K when this happens. That does not mean that the HDSP 9652 is also jumping to 48K. Possibly the HDSP 9652 stops sending a sync signal, or does something else strange. The same noise occurs when I simply change sample rates using hdspconf. For this reason, I started thinking that it was a problem like Steve's since I imagined that if all zeros were sent to the buffer while the rate was being changed it might eliminate that problem. Or possibly this has to do with the specific way I have things hooked up? HDSP 9652 is the clock Master Clocks to slaves are over ADAT ADAT-1 <==> Pro Tools/Win XP system ADAT-2 <==> Alesis AI-3 ---> Speakers & headphone amps ADAT-3 <==> Hammerfall Light/WinME/GigaStudio/Reaktor-or-Linux soft synths Maybe this is an ADAT-2 problem specifically and wouldn't happen if the Alesis was on ADAT-1? Thanks for your help. Mark > > Ok, it's a thing that we would like to eliminate, but when I tried to > figure what's going on in the past, I wasn't successful. The best > thing to > measure if ALSA sends a wrong sample sequence to the output is to use the > digital I/O (S/PDIF or profi IEC958) for on playback side and capture the > whole stream on the other side. > > It seems to me, that some audio hardware (in the analog path) does not > have compensation for the big volume change at the start or stop of the > PCM stream. In this case, the application must do this compensation itself > to avoid the clicks. It's difficult to do the stream modification in the > driver. > > Jaroslav > > - > Jaroslav Kysela <[EMAIL PROTECTED]> > Linux Kernel Sound Maintainer > ALSA Project, SuSE Labs > > --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Pops at start of song
> > Ok, it's a thing that we would like to eliminate, but when I tried to > figure what's going on in the past, I wasn't successful. The best > thing to > measure if ALSA sends a wrong sample sequence to the output is to use the > digital I/O (S/PDIF or profi IEC958) for on playback side and capture the > whole stream on the other side. > Jaroslav, I tried a number of times over the weekend to accomplish this, but it turns out it's somewhat harder than I expected. Please tell me if any of this is of interest. Again, the HDSP 9652 is the master clock. All the other devices receive their clocks via their ADAT connections. MasterSlaves via ADAT s/pdif <> Pro Tools (no clock) ADAT-1 <> Pro Tools (clock) ADAT-2 <> Alesis AI-3 ADAT-3 <> GigaStudio Also, I set up audio connections from the AI-3 to Pro Tools to record the pop/glitch noise: AI-3 ---> Pro Tools audio input At this point I tried a number of things: 1) With the Pro Tools PC synced to the HDSP 9652 via ADAT I can start recording. However, anytime the problem occurs and the HDSP 9652 momentarily changes it's clock frequency, the Pro Tools hardware complains and immediately stops recording. This does not capture anything of interest. 2) I can run both the Pro Tools PC and the HDSP 9652 at 44.1KHz, but unsynced. In this case I can capture digital audio of the problem, but since the two are unsynced I also get normal clicks and pops that are expected when you do this. If you think you can get information from this file I'll send it to you. Possibly, if I sent you all 5 stereo files captured digitally via ADAT and s/pdif you'd get more info since the problem occurs on all 10 channels and both cables at the same time. 3) I can run both unsynced again, but I record the audio glitch using the Pro Tools A/D's. This works fine, but it isn't pure digital information so I expect that it's not of that much interest. One thing I noted was that when Pro Tools and the HDSP 9652 run unsynced there is far more digital noise on ADAT-2, channels 7 & 8 than on the other 6 channels. I can see no reason for this, but it happens. If you get a chance to respond today then I'll get you what I can quickly. I'll be traveling after Tuesday evening California time so nothing will come for about a week after that. Thanks for trying to help! Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Pops at start of song
> > Ok, can you force the master rate for HDSP? Yes, I can force the HDSP master rate to be 44.1KHz. I can then force the Pro Tools PC be a master also, at 44.1K, but there will be random clicks and pops since the two are not synced to each other. If I do this and record on the Pro Tools PC, I get all zeros with a random click here and there. This is the only way I can record using Pro Tools as the problem with the HDSP happens and shuts down Pro Tools since it doesn't like the clock changing. (I.e. - the Pro Tools session is 44.1K, and the clock changes to 48K, so it gets upset and stops recording.) > Then you can simply send some > short (a few seconds) .wav file (or other file) with same rate to selected > channels (maybe via aplay if you have a good configuration in > ~/.asoundrc). There is no problem when using aplay, or at least using alsaplayer there isn't. I've never had these problems with any Alsa application. Only with apps that seem to use the OSS emulator, I think. I will try to get the noise recorded when using xmms. You should get zeros leading in, then this noise, and then the audio. > Then you can compare (maybe via some editor) if the whole > .wav file is in the recorded stream (plus some zero samples at begging and > end of this stream). Or, you can send me your source and recorded files > and I'll compare them for you (only mark which file is master). > > Jaroslav I've just set up an apache server at home, so later today I'll put the audio files there, and then give you an IP address where you can pick them up. What time zone are you in by the way? Thanks very much, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Pops at start of song
> > Then you can compare (maybe via some editor) if the whole > > .wav file is in the recorded stream (plus some zero samples at > begging and > > end of this stream). Or, you can send me your source and recorded files > > and I'll compare them for you (only mark which file is master). > > > > Jaroslav > > I've just set up an apache server at home, so later today I'll > put the audio > files there, and then give you an IP address where you can pick them up. > What time zone are you in by the way? > > Thanks very much, > Mark Hi, Couldn't get the web server to serve the files, so I've sent them zipped by email. Cheers, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Pops at start of song
Thomas & Jaroslav, Here's a graphical representation of the noise problem I'm having using the HDSP 9652. The attached png file shows the wave file I'm playing on the top line, and then two separate outputs from the HDSP 9652. The two separate Pro Tools captures were done at the same time and are definitely in sync. I have adjusted the wave file input to be in line with where it probably was when I played the file. The next line shows what's captured by Pro Tools over the ADAT-2 cable. It appears the first .1 Sec is not transferred by the HDSP 9652. The final group shows what is captured by Pro Tools on an audio input that is the same as my main speaker output. Levels are reduced a bit since I have hdspmixer cutting the level a bit, but you can clearly see the noise at the beginning, which is very loud, and then the same delay before the actual audio starts playing. This last group is ADAT-1 out going to the AI-3 and then into a Pro Tools input. I hope this helps explain the problem. Cheers, Mark HDSPnoise.xpm.gz Description: GNU Zip compressed data
Re: [Alsa-devel] ALSA 1.0.0rc1 released
Hi, I want to report that I've built alsa-1.0.0rc1 under Gentoo with q 2.4.20-r7 kernel. Thanks to Thomas Charbonnel for the help with the ebuilds. If any other Gentoo users need the ebuilds, then contact me off list. Unfortunately this release does not impact my loud glitch/pop noise on the HDSP 9652 when using OSS applications. The results are the same as I reported over the last few weeks. I have not run significant Alsa audio yet to talk about how that's working. The OSS fix was the one I was most hoping for, and I haven't had many Alsa problems anyway. - Thanks, Mark On Mon, 2003-12-01 at 05:54, Takashi Iwai wrote: > Hi, > > today we reached ALSA 1.0.0rc1 release. > as its name stands, this is the "release candidate" for 1.0.0. > if no show-stopper bug is reported, we'll release 1.0.0 really > soon. > > this version includes the following fixes since the last 1.0.0-pre3 > release. > > Drivers: > - fixed OSS emulation on kernel. quake and wine should work now. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA 1.0.0rc1 released
On Tue, 2003-12-02 at 10:16, Steve deRosier wrote: > We went ahead and added code to our alsa client software to cleanly > return to a PCM value of 0 and then stuffed a full buffer worth of 0s > into the buffer before closeing the PCM in order to solve our pop > problem. I'm not sure how the OSS emulation stuff works since we don't > use it, but maybe it could use this same treatment? I'm assuming we > don't want to change OSS client programs to fix it, so that would leave > something in the emulation layer that should be changed. Perhaps OSS > automagically does this cleanup? Mark, have you tried using the real > OSS? Do the pops happen with OSS? No, I haven't tried real OSS. I'm fairly new to Linux audio and have never used anything other than Alsa in all it's glory. I don't know how OSS would be installed under Gentoo. I don't see any ebuilds for it. I presume it will work if I build it from source by hand, but that does sound like a lot of work. In my current case the pops only happen with OSS emulation under Alsa. All files that create pops using OSS emulation work perfectly if I use any native Alsa app to play them, so I really don't think it's the source material itself. I wish I didn't have to use OSS at all. Has anyone accomplished getting all types of web-based multi-media to work just using Alsa? Any mime.type files to lead the way? - Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Wine failures with Alsa 1.0.0rc1
** Thu Dec 4 04:41:38 2003 Starting '/opt/cxoffice/bin/wineloader' '--' 'winepath.exe' '--long' '--' '/home/mark/.cxoffice/dotwine/fake_windows/SIERRA/CAESAR3DEMO/c3.exe' Argument conversion: [/home/mark/.cxoffice/dotwine/fake_windows/SIERRA/CAESAR3DEMO/c3.exe] -> [C:\SIERRA\CAESAR3DEMO\c3.exe] Command: /opt/cxoffice/bin/wineloader winewrapper.exe cxoffice -- C:\SIERRA\CAESAR3DEMO\c3.exe ** Thu Dec 4 04:41:38 2003 Starting '/opt/cxoffice/bin/wineloader' 'winewrapper.exe' 'cxoffice' '--' 'C:\SIERRA\CAESAR3DEMO\c3.exe' fixme:imm:ImmAssociateContext ((nil), 0x404c3350): semi-stub fixme:imm:ImmAssociateContext ((nil), 0x404c2e20): semi-stub fixme:imm:ImmAssociateContext ((nil), 0x40502838): semi-stub err:module:BUILTIN32_LoadLibraryExA failed to load .so lib for builtin winealsa.drv: /opt/cxoffice/lib/wine/winealsa.drv.so: undefined symbol: snd_pcm_playback_drain err:module:NE_LoadBuiltinModule failed to load .so lib for 16-bit builtin winealsa.drv: /opt/cxoffice/lib/wine/winealsa.drv.so: undefined symbol: snd_pcm_playback_drain bash-2.05b$ >From the Wine config file: ; Uncomment the "Drivers" line matching your sound setting. ;"Drivers" = "wineoss.drv" ; default for most common configurations ;"Drivers" = "winearts.drv"; for KDE "Drivers" = "winealsa.drv"; for ALSA users ;"Drivers" = "winejack.drv"; for Jack sound server ;"Drivers" = "winenas.drv" ; for NAS sound system ;"Drivers" = "wineaudioio.drv" ; for Solaris machines ;"Drivers" = ""; to disable sound "WaveMapper" = "msacm.drv" "MidiMapper" = "midimap.drv" --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] aoss failures under Alsa-1.0.0rc1
bash-2.05b$ aoss xmms
(At this point the xmms gui opens. I then press play)
xmms: alsa-oss.c:222: oss_dsp_hw_params: Assertion `err >= 0' failed.
/usr/bin/aoss: line 9: 2841 Aborted
LD_PRELOAD=${exec_prefix}/lib/libaoss.so $*
bash-2.05b$
Contents of my .asoundrc file:
pcm.hdsp {
type hw
card 0
}
ctl.hdsp {
type hw
card 0
}
pcm_slave.hdsp {
pcm "hw:0"
channels 26
}
pcm.playback_5_6 {
type dshare
slave hdsp
ipc_key 314159265# some unique number
ipc_key_add_uid yes # "no" to let multiple users share it
bindings {
0 5
1 6
}
}
pcm.dsp0 {
type plug
slave.pcm playback_5_6
}
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] aoss failures under Alsa-1.0.0rc1
On Thu, 2003-12-04 at 05:06, Mark Knecht wrote:
> bash-2.05b$ aoss xmms
>
> (At this point the xmms gui opens. I then press play)
>
> xmms: alsa-oss.c:222: oss_dsp_hw_params: Assertion `err >= 0' failed.
> /usr/bin/aoss: line 9: 2841 Aborted
> LD_PRELOAD=${exec_prefix}/lib/libaoss.so $*
> bash-2.05b$
>
BTW - hdspconf says that aoss xmms sets the sample rate to 48K when this
fails, even though the media is recorded at 44.1K.
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] aoss failures under Alsa-1.0.0rc1
> > (At this point the xmms gui opens. I then press play)
> >
> > xmms: alsa-oss.c:222: oss_dsp_hw_params: Assertion `err >= 0' failed.
> > /usr/bin/aoss: line 9: 2841 Aborted
> > LD_PRELOAD=${exec_prefix}/lib/libaoss.so $*
> > bash-2.05b$
>
> fixed recently - at least it won't abort but returns an error.
> but i'm not sure whether the OSS emulation with dmix now works in your
> case...
>
Takashi,
Thanks for the response. Does it make sense to change dshare to dmix? The
goal was to get OSS emulation to only use 2 channels of my HDSP 9652. Or are
you saying I need rc2?
Also, why does aoss change the sample rate from 44.1K to 48K?
Thanks,
Mark
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Wine failures with Alsa 1.0.0rc1
> > it's a very old symbol used only in ALSA 0.5.x. > most likely the detection code in wine is broken, typically checking > only SND_MINOR_VERSION and not checking SND_MAJOR_VERSION. > if so, the wine driver believes that it's a 0.5.x, since the minor > version is 0 now. > > > Takashi Thanks Takashi. I'm running Codeweavers Crossover Office, so I'll pass this on to them first. Possibly I'll also try Transgaming's version of Wine which is likely newer and more up to date. - Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Can't set 88.2/96kHz samplerate with Hammerfall
> > Whenever I try to activate double speed (88.2/96kHz) mode with my RME > Hammerfall Lite (DIGI 9636), snd_pcm_hw_params fails with a 'Device or > resource busy' message. This is with the number of channels set to 10, > since the number of ADAT channels is halved. Is this a known > defect of the > Hammerfall driver? > > Thanks > > Arve Knudsen >From the Hammerfall Light Alsa sound card page: Known bugs - 96kHz and 88.2kHz not accessible via PCM interface --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Can't set 88.2/96kHz samplerate with Hammerfall
> > > > From the Hammerfall Light Alsa sound card page: > > > > Known bugs > > > > - 96kHz and 88.2kHz not accessible via PCM interface > Ok, thanks. I suppose I should've investigated a little better. > Too bad, I > would like to see this card working as well as under Windows. > > Regards > > Arve Knudsen Me too. I own the same card in one of my systems. This is really the downside to Linux audio. Without dedicated developers that own the cards and continue working on improvements support stalls out. The best I've been able to determine is that this card last got a real facelift over a year ago and since then nothing. I've grown to accept that it will never happen, and will be overjoyed that was if and when it finally does. Don't expect anything soon, unless you're willing to be that developer. BTW - if you get a chance, take a look at /proc/asound/card0/hdsp (modify the card number if required and I'm guessing on the hdsp part) and see if it's listing spdif under the status section? Mine doesn't, or didn't, the last time I looked. It indicated 3 ADAT ports which this card does not have. - Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] aoss failures under Alsa-1.0.0rc1
On Thu, 2003-12-04 at 05:15, Erik Inge Bolsø wrote:
> On Thu, 4 Dec 2003, Mark Knecht wrote:
> >pcm.playback_5_6 {
> > type dshare
> > slave hdsp
> Uhmm... for _playback_, shouldn't that be "type dmix"? Or am I confused
> again?
>
I tried dmix instead of dshare but get the same results. I guess I hope
that Clemens or possibly Thomas jumps in with some ideas. I don't know
if this is an Alsa problem, a driver problem, or just something that
will never work because of my card's capabilities?
If the later is the case, then is this something that should/could be
better spelled out so that well meaning but uneducated folks like me
don;t keep bothering you guys?
Thanks,
Mark
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] aoss failures under Alsa-1.0.0rc1
On Fri, 2003-12-05 at 05:10, Clemens Ladisch wrote: > > I don't know if this is an Alsa problem, a driver problem, or just > > something that will never work because of my card's capabilities? > > An aoss problem, I think. Are you using the latest CVS version? > (You can update this single package independantly of the other ALSA > packages.) > I am using 1.0.0.rc1 on Gentoo with a 2.4.20-r9 kernel. I got the same behavior on 0.9.8 and reported it but never got a response. Thanks, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] aoss failures under Alsa-1.0.0rc1
> > I am using 1.0.0.rc1 on Gentoo with a 2.4.20-r9 kernel. I got the same > behavior on 0.9.8 and reported it but never got a response. > I didn't see an announcement, but the Alsa page now shows 1.0.0rc2. Are you suggesting that this might actually have been fixed in rc2? If so, what was the cause? --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] aoss failures under Alsa-1.0.0rc1
> > There is a change in alsa-oss.c, immediately after rc1 came out, with > the following log message: > > - avoid the assert in snd_pcm_drain(). > - fixed the possible segfault at the wrong release of resources. > - more debug messages. > Clemens, Thanks. In this case I will either make the effort to modify the Gentoo ebuild myself, or wait for Gentoo to catch up. They were only 2 days behind this time on rc1 making me think an Alsa developer must be right in the ebuild loop these days. Thanks for all your help. Hopefully we can get this working soon. Cheers, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] aoss failures under Alsa-1.0.0rc1
> > There is a change in alsa-oss.c, immediately after rc1 came out, with > the following log message: > > - avoid the assert in snd_pcm_drain(). > - fixed the possible segfault at the wrong release of resources. > - more debug messages. > > > HTH > Clemens Clemens, rc2 is not working yet, but it is much improved and not crashing. I now get a warning in the terminal when I run 'aoss xmms' from oss_open() saying it cannot find /dev/sound/dsp, and a nice (I think xmms) dialog box asking me to check that I have the right output plugin, no programs are blocking and that the soundcard is configured properly. So, what do I need to do to solve this? /dev/sound/dsp seems to exist, but it's one of those yellow special file thingies. How about something in .asoundrc? My oss playback definition is for pcm.dsp0. I'm remote from the machine and looking at the xmms display, but I tried changing the OSS thing we were working on to pcm.dsp and xmms seems to be working, in the sense that it isn't crashing. However, hdspmixer (being run over an ssh connection!) looks like the audio is on playback_1/2 instead playback_5/6, so this isn't completely right yet. And, since I'm remote I don't know what this sounds like, but I presume it's OK. I'll let you know in 5-6 hours. Anyway, rc2 is much better. aoss is happy even if I'm not. (YET!!!) Thanks, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Alsa-1.0.0rc2 Hammerfall Light - small bug report
Hi, The Hammerfall Light driver has a couple of small bugs in the way it identifies port status in /proc/asound where it lists the spdif port as an ADAT port. I'm not using spdif on this machine so I cannot check to see if it shows lock status correctly. Someone may want to look at this. Cheers, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Alsa-1.0.0rc2 Hammerfall Light - small bug report
On Sat, 2003-12-06 at 17:28, Mark Knecht wrote: > Hi, >The Hammerfall Light driver has a couple of small bugs in the way it > identifies port status in /proc/asound where it lists the spdif port as > an ADAT port. I'm not using spdif on this machine so I cannot check to > see if it shows lock status correctly. Someone may want to look at this. > > Cheers, > Mark Sorry. Forgot to attach what I saw. Note ADAT3 which do not exist on this card. [EMAIL PROTECTED] mark]$ cat /proc/asound/card0/rme9652 RME Digi9636 (Rev 1.5) (Card #1) Buffers: capture ee40 playback ee00 IRQ: 10 Registers bus: 0xf500 VM: 0xf091d000 Control register: 44006 Latency: 512 samples (2 periods of 2048 bytes) Hardware pointer (frames): 0 Passthru: no Clock mode: autosync Pref. sync source: ADAT1 ADAT1 Input source: ADAT1 optical 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 ADAT1: No Lock ADAT2: No Lock ADAT3: No Lock Timecode signal: no Punch Status: 1: off 2: off 3: off 4: off 5: off 6: off 7: off 8: off 9: off 10: off 11: off 12: off 13: off 14: off 15: off 16: off 17: off 18: off [EMAIL PROTECTED] mark]$ --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Alsa-OSS - Pop at start of song update (rc2)
Hi, This is a small update on the problem I've seen with loud pops and crackles at the start of audio when using Alsa's OSS emulation. As background, using xmms I am unable to play about 99% of the mp3, ogg and wave files I have without getting a very loud noise when first starting the playback. The noise also happens every time I pause and restart the playback. It also happens with pretty much every audio or video viewed and played by Mozilla. mplayer, xine, plugger-5.0 all have default setups that cuase this on my system. However, an interesting aspect was that this does not ever happen when playing any of these files with an Alsa application instead. Using that as a clue, I tried using alsaplayer through the oss layer instead of directly into Alsa, using alsaplayer -o oss It turns out that this NEVER causes the noise. All mp3, ogg and wave files play correctly using alsaplayer through the OSS layer. I'm not sure what this says, really. If alsaplayer can talk to the OSS layer correctly, then you could say that every other app I've tried is bad and all those apps need to be recoded. On the other hand, if so many apps fail in my system, then is the problem with the OSS emulation interface and that needs to be looked at? I also tried building the alsa-xmms plugin, but it fails with Alsa-1.0.0rc2, so I'll file bug reports on that elsewhere. Thanks, Mark Postscript: Without support from a developer somewhere who is interested in solving this I understand that this is not going to go much further than this message. The problem has been there, and I have been reporting it in one form or another for over 8 months. No one has stepped up to solve it specifically, and not being a developer this is about as much as I can do. I don't know what else I can do to muster some interest in solving it. This is an RME product, which is one of the 'preferred' hardware manufacturers for Linux audio. It's burning me today. It will burn others later. Clearly I get that this problem occurs on very few systems, so I get that it's not high priority. Maybe there's nothing that can get done about it. That would be disappointing. From a practical point of view, this one problem pretty much causes me to have to drop using Linux at all for browsing the web and is forcing me back to Windows. I cannot handle super loud ugly noises at the start of playing a simple 2-second wave file. A lot of what I do is on the web, and every one plays badly on my system. Bummer... The only practical idea I can offer is that someone in the Alsa camp should take up the task of developing a set of instructions for configuring Mozilla. et. all, in such away as to make OSS not be used. I think Alsa should support, but not depend on, OSS at all. Today it depends on OSS by not providing clear info on how to use Alsa inside of browsers. --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] 1.0.0rc2 report on aoss
Hi,
I've was asked to try 1.0.0rc2 aoss support and to report back on my
results. This email intended to do that. Bottom line is rc2 is better
than previous versions, but nothing is working 100% as expected.
1) My .asoundrc file is at the end of this message.
2) If I run xmms using OSS I get audio on all 26 playback channels and
pops at the start of playback.
3) If I run 'aoss xmms' I get audio on playback channels 1 & 2 instead
of 5 & 6 as specified.
4) If I run 'alsaplayer -o oss' I get audio on all 26 channels and no
pops at the start of playback.
5) If I run 'aoss alsaplayer -o oss' aoss dies:
bash-2.05b$ aoss alsaplayer -o oss
/usr/bin/aoss: line 9: 2650 Segmentation fault
LD_PRELOAD=${exec_prefix}/lib/libaoss.so $*
bash-2.05b$
Please let me know if something else needs to be tested, but there
are two problems at least here that should be looked into.
Thanks,
Mark
pcm.hdsp {
type hw
card 0
}
ctl.hdsp {
type hw
card 0
}
pcm_slave.hdsp {
pcm "hw:0"
channels 26
}
pcm.playback_5_6 {
type dshare
slave hdsp
ipc_key 314159265# some unique number
ipc_key_add_uid yes # "no" to let multiple users share it
bindings {
0 5
1 6
}
}
pcm.dsp {
type plug
slave.pcm playback_5_6
}
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Alsa-OSS - Pop at start of song update (rc2)
On Sun, 2003-12-07 at 10:28, Patrick Shirkey wrote: > (Some people have been known to > invest in a second $10 card just for browsing). Sure. I've got an on-board sound chip of some type. I used to have it enabled. Sounds like I probably need to do something like that and patch it with a cable back into the RME which would get the audio sent to speakers and headphones. I think this problem is unlikely to ever get addressed seriously. However, as I remember it, there were conflicts having both the on-board chip and the RME both on at the same time. MIDI stuff or something like that. Cheers, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] rc2 - snd-via82xx - really sounds bad - distorted, resampled, phasey
On Sun, 2003-12-07 at 10:28, Patrick Shirkey wrote:
> (Some people have been known to
> invest in a second $10 card just for browsing).
>
Patrick,
Hi. Ok, since you suggested it I set up this Via 8235 sound chip on
my system as the primary sound chip. However, it's sounding amazingly
bad! It's terribly distorted and even at the best of times sounds very,
very,phasey. I can pretty much hear what sound like terrible resampling
noise, maybe like it's going from 44.1K up to 48K or something.
Any idea why? I hope it's just a configuration mistake.
I've tried both alsaplayer and xmms playing a few mp3's and the results
are always the same going through the 8235.
The 8235 output is cabled to an input on the AI-3 A/D, inputs 3/4. I've
also got Pro Tools coming in on inputs 1/2. Audio from Pro Tools is
fine, while audio from the 8235 is dirty, resampled and phasey. The AI-3
does not show any clipping on the signal coming from the 8235, so I
don't think it's really a levels issue.
Is the 8235 a 44.1K only type device? I don't think so since I see 44.1K
number in /proc/asound/card0/
I haven't figured out how to run alsaplayer directly though Alsa when
the HDSP is the second card, but using Jack I can run alsaplayer and the
sound is much better.
I think there have been similar comments since rc1 about this sort of
thing on the Intel sound chips possibly? Are others using rc2
successfully with this chip or could this be a similar problem?
The sound is so bad as to be unlistenable.
Current .asoundrc and modules.conf below...
Thanks,
Mark
pcm.via82xx {
type hw
card 0
}
ctl.via82xx {
type hw
card 0
}
pcm.hdsp {
type hw
card 1
}
ctl.hdsp {
type hw
card 1
}
pcm_slave.hdsp {
pcm "hw:0"
channels 26
}
pcm.playback_5_6 {
type dshare
slave hdsp
ipc_key 314159265# some unique number
ipc_key_add_uid yes # "no" to let multiple users share it
bindings {
0 5
1 6
}
}
pcm.dsp {
type plug
slave.pcm playback_5_6
}
# ALSA portion
alias char-major-116 snd
# OSS/Free portion
alias char-major-14 soundcore
##
## IMPORTANT:
## You need to customise this section for your specific sound card(s)
## and then run `update-modules' command.
## Read alsa-driver's INSTALL file in /usr/share/doc for more info.
##
## ALSA portion
alias snd-card-0 snd-via82xx
alias snd-card-1 snd-hdsp
alias snd-card-2 snd-usb-audio
## OSS/Free portion
alias sound-slot-0 snd-card-0
alias sound-slot-1 snd-card-1
alias sound-slot-2 snd-card-2
##
# OSS/Free portion - card #0 (Via8233)
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
# OSS/Free portion - card #1 (HDSP9652)
alias sound-service-1-0 snd-mixer-oss
alias sound-service-1-1 snd-seq-oss
alias sound-service-1-3 snd-pcm-oss
alias sound-service-1-8 snd-seq-oss
alias sound-service-1-12 snd-pcm-oss
alias /dev/mixer snd-mixer-oss
alias /dev/dsp snd-pcm-oss
alias /dev/midi snd-seq-oss
# Set this to the correct number of cards.
options snd cards_limit=3
add options -k snd-card-0
add options -k snd-card-1
add options -k snd-card-2
### modules-update: end processing /etc/modules.d/alsa
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] rc2 - snd-via82xx - really sounds bad - distorted, resampled, phasey
On Sun, 2003-12-07 at 20:53, [EMAIL PROTECTED] wrote:
> Hi, I have that exact same problem with a via8235 chip, and the only way
> I have found to fix it was to change 48000 to 44100 on Line 83 in
> alsa-kernel/pci/via82xx.c:
> static int ac97_clock[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 48000};
> I actuially wrote a mail earlier today on the same subject (called
> viasomehting8235 clock problems or something). It seems to work fine
> after I make this change, btw.
>
> 784 - Michael C. Piantedosi - [EMAIL PROTECTED]
Interesting info. Thanks.
- Mark
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] VT8233/A/8235 Clock Problem
On Mon, 2003-12-08 at 01:05, Clemens Ladisch wrote:
> [EMAIL PROTECTED] wrote:
> > Hi, I've got a motherboard with a builtin soundcard, proc/pci says:
> > VIA Technologies, Inc. VT8233/A/8235 AC97 Audio Controller (rev 80)
> > (The Mobo is a Gigabyte GA-7VAX, a VIA KT400 chipset with a VT8235)
> >
> > and I find that (on Line 83 in alsa-kernel/pci/via82xx.c) the:
> > static int ac97_clock[SNDRV_CARDS] = {[0 ... (SNDRV_CARDS - 1)] = 48000};
> >
> > ...works better for me when the 48000 is changed to 44100.
>
> This is a module option; instead of changing this line, you are
> supposed to put the following line into modules.conf:
>
> options snd-via82xx ac97_clock=44100
>
> (or, if an options line for this module already exists, add it there)
>
>
> HTH
> Clemens
>
Clemens,
This is helpful. I'm having similar problems, so I'll try this out
later today.
BTW - how can I get a list of all possible module options for a given
card or device? Is there any way to find out about this without reading
the code?
Thanks,
Mark
---
This SF.net email is sponsored by: SF.net Giveback Program.
Does SourceForge.net help you be more productive? Does it
help you create better code? SHARE THE LOVE, and help us help
YOU! Click Here: http://sourceforge.net/donate/
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] VT8233/A/8235 Clock Problem
On Mon, 2003-12-08 at 07:49, Clemens Ladisch wrote: > Mark Knecht wrote: > >BTW - how can I get a list of all possible module options for a given > > card or device? Is there any way to find out about this without reading > > the code? > > modinfo snd-via82xx Cool. Thanks. I don't see explanations of the ac97_clock settings. Wizard root # modinfo snd-via82xx filename: /lib/modules/2.4.20-gentoo-r9/kernel/sound/pci/snd-via82xx.o description: "VIA VT82xx audio" author: "Jaroslav Kysela <[EMAIL PROTECTED]>" license: "GPL" parm:index int array (min = 1, max = 8), description "Index value for VIA 82xx bridge." parm:id string array (min = 1, max = 8), description "ID string for VIA 82xx bridge." parm:enable int array (min = 1, max = 8), description "Enable audio part of VIA 82xx bridge." parm:mpu_port long array (min = 1, max = 8), description "MPU-401 port. (VT82C686x only)" parm:ac97_clock int array (min = 1, max = 8), description "AC'97 codec clock (default 48000Hz)." parm:dxs_support int array (min = 1, max = 8), description "Support for DXS channels (0 = auto, 1 = enable, 2 = disable , 3 = 48k only, 4 = no VRA)" Wizard root # man modinfo Is this what I would look at to see the results of changing this parameter? Wizard root # cat /proc/asound/card0/codec97#0/ac97#0-0 0-0/0: Realtek ALC650 rev 2 Capabilities : DAC resolution : 20-bit ADC resolution : 18-bit 3D enhancement : Realtek 3D Stereo Enhancement Current setup Mic gain : +0dB [+0dB] POP path : pre 3D Sim. stereo : off 3D enhancement : off Loudness : off Mono output : MIX Mic select : Mic1 ADC/DAC loopback : off Extended ID : codec=0 rev=1 LDAC SDAC CDAC DSA=0 SPDIF DRA VRA Extended status : SPCV LDAC SDAC CDAC SPDIF=res VRA PCM front DAC: 48000Hz PCM Surr DAC : 48000Hz PCM LFE DAC : 48000Hz PCM ADC : 48000Hz SPDIF Control: Consumer PCM Category=0x2 Generation=1 Rate=48kHz SPDIF In Status : Not Locked Wizard root # > > or read alsa-kernel/Documentation/ALSA-Configuration.txt and a number of us were looking for this the other day and couldn't find it: Wizard root # slocate ALSA-Configuration.txt Wizard root # I guess not all distributions install it, so I hope you will forgive me not being able to read it without doing extra work. Possibly it's in a zipped tarball somewhere... > alsa-driver/INSTALL. > > > HTH > Clemens > > --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] VT8233/A/8235 Clock Problem
On Mon, 2003-12-08 at 01:05, Clemens Ladisch wrote: > This is a module option; instead of changing this line, you are > supposed to put the following line into modules.conf: > > options snd-via82xx ac97_clock=44100 > > (or, if an options line for this module already exists, add it there) > > > HTH > Clemens Clemens, Hi. This option did not fix my sound problems with the Via 8235. It still sounds like it's resampling the sound. I hear artifacts all over the place. I do think the option worked since the PCM stuff now says it's running at 44100, but I wonder if there is another option for the spdif side, or is there a bug in that the driver should be setting this at the same time? I'm not using spdif on this motherboard, but possibly when it runs at 48K that makes the hardware do something to the PCM data? alsaplayer and xmms both sound equally bad though OSS. alsaplayer says it's playing at 44100. alsaplayer through Jack and my HDSP 9652 sounds good. Any other ideas about what to try? - Mark Wizard root # !cat cat /proc/asound/card0/codec97#0/ac97#0-0 0-0/0: Realtek ALC650 rev 2 Capabilities : DAC resolution : 20-bit ADC resolution : 18-bit 3D enhancement : Realtek 3D Stereo Enhancement Current setup Mic gain : +0dB [+0dB] POP path : pre 3D Sim. stereo : off 3D enhancement : off Loudness : off Mono output : MIX Mic select : Mic1 ADC/DAC loopback : off Extended ID : codec=0 rev=1 LDAC SDAC CDAC DSA=0 SPDIF DRA VRA Extended status : SPCV LDAC SDAC CDAC SPDIF=res SPDIF VRA PCM front DAC: 44100Hz PCM Surr DAC : 44100Hz PCM LFE DAC : 44100Hz PCM ADC : 44100Hz SPDIF Control: Consumer PCM Category=0x2 Generation=1 Rate=48kHz SPDIF In Status : Not Locked Wizard root # --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] VT8233/A/8235 Clock Problem
> Most likely you need the dxs_support option instead of ac97_clock. > > With dxs_support=2 the sound should work fine, but the hardware mixing > capability will be disabled. Then you can try dxs_support=1 or > dxs_support=4. > > By default snd-via82xx uses dxs_support=3 (except for certain known > motherboards), this makes only 48000 sampling rate available. The > ALSA library can perform resampling for ALSA apps, and the kernel OSS > emulation layer can do resampling for OSS apps, but the quality is > often not good. > Sergey, This sounds encouraging. For those of us not in the know, can you tell me anything about *what* dxs support is? Just point me at a web site with an explanation if you have one. And what are dxs options 1, 2, 3 & 4 really doing? Does this 2-channel motherboard sound chip actually do hardware mixing? Or is that for other sound chips in this family? I'll try them all out later today. Thanks, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] VT8233/A/8235 Clock Problem - good results, some possible bugs?
On Mon, 2003-12-08 at 13:04, Sergey Vlasov wrote: > Most likely you need the dxs_support option instead of ac97_clock. > > With dxs_support=2 the sound should work fine, but the hardware mixing > capability will be disabled. Then you can try dxs_support=1 or > dxs_support=4. > > By default snd-via82xx uses dxs_support=3 (except for certain known > motherboards), this makes only 48000 sampling rate available. The > ALSA library can perform resampling for ALSA apps, and the kernel OSS > emulation layer can do resampling for OSS apps, but the quality is > often not good. Sergey, Thanks for sending me down this path. Definitely I'm getting better results now. I did find some things out though. Some may possibly be bugs: 1) On my system dxs_support=3 is NOT the same as not setting dxs_support at all. With dxs_support not set I get horrible results. With dxs_support=3 I get reasonable to good results. 2) **ALL** applications I tried (alspalayer, gxine & xmms) are overdriving the audio path somewhere and causing distortion. The output level from the motherboard is not hot. In fact, even when the apps are up full the output level is actually down about 12-15db from where I'd like it, but I'm getting lots of distortion. When I reduce alsaplayer's level the distortion mostly goes away, although I'm left with considerable background hiss. In all cases I monitored the return level and it never causes my inputs to clip. (This level difference may be a pro equipment/consumer equipment issue.) 3) With dxs_support=1 I get very bad sounding results. It appears that there is a bug in the ADC setting. PCM ADC is set to 48K. I think this is the mode I would really like to use if PCM ADC was set to 44.1K, but as it is it sounds terrible. dxs=2 is not very good, and dxs=3/4 are both pretty good. All modes have a lot of hiss compared to my HDP 9652 and outboard D/A. (Expected...) cat /proc/asound/card0/codec97#0/ac97#0-0 dxs=1dxs=2 dxs=3/4 PCM front DAC: 44100Hz 22050Hz 48000Hz PCM Surr DAC : 44100Hz 22050Hz 48000Hz PCM LFE DAC : 44100Hz 22050Hz 48000Hz PCM ADC : 48000Hz 22050Hz 48000Hz SPDIF Control: 44.1kHz 44.1kHz 48000Hz Sound Quality: BAD!!not goodGood So, I am currently using Mode 4 and getting pretty good results, although I think Mode 1 would be even better for me if the PCM ADC was set to the right value. Cheers, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] VT8233/A/8235 Clock Problem - good results, some possible bugs?
On Tue, 2003-12-09 at 02:21, Sergey Vlasov wrote:
> On Mon, Dec 08, 2003 at 08:08:37PM -0800, Mark Knecht wrote:
> > On Mon, 2003-12-08 at 13:04, Sergey Vlasov wrote:
> >
> > > Most likely you need the dxs_support option instead of ac97_clock.
> > >
> > > With dxs_support=2 the sound should work fine, but the hardware mixing
> > > capability will be disabled. Then you can try dxs_support=1 or
> > > dxs_support=4.
> > >
> > > By default snd-via82xx uses dxs_support=3 (except for certain known
> > > motherboards), this makes only 48000 sampling rate available. The
> > > ALSA library can perform resampling for ALSA apps, and the kernel OSS
> > > emulation layer can do resampling for OSS apps, but the quality is
> > > often not good.
> >
> > Sergey,
> >Thanks for sending me down this path. Definitely I'm getting better
> > results now. I did find some things out though. Some may possibly be
> > bugs:
> >
> > 1) On my system dxs_support=3 is NOT the same as not setting dxs_support
> > at all. With dxs_support not set I get horrible results. With
> > dxs_support=3 I get reasonable to good results.
>
> This means that you board in known to the driver...
>
> There is an entry for a similar model in the driver:
>
> { .vendor = 0x1458, .device = 0xa002, .action = VIA_DXS_ENABLE }, /* Gigabyte
> GA-7VAXP */
>
> The IDs checked here are the PCI subsystem vendor/device ID of the sound
> device. Run "lspci -v" and find "Multimedia audio controller" in the
> output, then look at the "Subsystem:" line. The vendor ID will probably
> be replaced by the corresponding name; you can find out the number by
> executing a command like "lspci -nv -s 00:07.5" (use the slot number for
> your audio controller which is shown in the lspci output).
>
> > 2) **ALL** applications I tried (alspalayer, gxine & xmms) are
> > overdriving the audio path somewhere and causing distortion. The output
> > level from the motherboard is not hot. In fact, even when the apps are
> > up full the output level is actually down about 12-15db from where I'd
> > like it, but I'm getting lots of distortion. When I reduce alsaplayer's
> > level the distortion mostly goes away, although I'm left with
> > considerable background hiss. In all cases I monitored the return level
> > and it never causes my inputs to clip. (This level difference may be a
> > pro equipment/consumer equipment issue.)
> >
> > 3) With dxs_support=1 I get very bad sounding results. It appears that
> > there is a bug in the ADC setting. PCM ADC is set to 48K. I think this
> > is the mode I would really like to use if PCM ADC was set to 44.1K, but
> > as it is it sounds terrible. dxs=2 is not very good, and dxs=3/4 are
> > both pretty good. All modes have a lot of hiss compared to my HDP 9652
> > and outboard D/A. (Expected...)
> >
> >
> > cat /proc/asound/card0/codec97#0/ac97#0-0
> >
> >dxs=1dxs=2 dxs=3/4
> >
> > PCM front DAC: 44100Hz 22050Hz 48000Hz
> > PCM Surr DAC : 44100Hz 22050Hz 48000Hz
> > PCM LFE DAC : 44100Hz 22050Hz 48000Hz
> > PCM ADC : 48000Hz 22050Hz 48000Hz
> > SPDIF Control: 44.1kHz 44.1kHz 48000Hz
> >
> > Sound Quality: BAD!!not goodGood
> >
> > So, I am currently using Mode 4 and getting pretty good results,
> > although I think Mode 1 would be even better for me if the PCM ADC was
> > set to the right value.
>
> Something strange is going on here...
>
> With dxs_support=1, the PCM DAC frequencies are set to match the mode
> requested by the software. Probably the VRA support in the onboard codec
> is not very good.
>
> Please show the complete contents of
> /proc/asound/card0/codec97#0/ac97#0-0.
The attached file has the output you asked for for all 5 possibilities,
none, 0,1,2,3. However, the 'none' setting was actually
option snd-via82xx dxs_support
with no number following, instead of no option statement at all. The
sound was the same bad sound, so I think this was probably not an issue.
I am disappointed that there is no option to set the PCM ADC to 44100 in
dxs_support=1. Is that something that could be changed in a future rev,
as in dxs_support=5 ? Since I work 100% of the time in 44100 it would
seem that this is requiring me to resample.
Thanks,
Mark
dxs_support=not set at all
Wizard root # !cat
cat /proc/asound/card0/codec97#0/ac97#0-0
0-0/0: Realtek ALC650 rev 2
Capabi
Re: [Alsa-devel] VT8233/A/8235 Clock Problem - good results, some possible bugs?
On Tue, 2003-12-09 at 05:35, Jaroslav Kysela wrote: > On Tue, 9 Dec 2003, Mark Knecht wrote: > > > I am disappointed that there is no option to set the PCM ADC to 44100 in > > ADC is for capture not for playback. Well, of course you are right about this. Is it 5:30AM where you are like it is here? (I should do more thinking!) ;-) Thanks Jaroslav. Then how do we explain that in dxs_support=2 my sound is so bad? I'm using 44.1KHz material and supposedly everything is running at 44.1KHz. - Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] VT8233/A/8235 Clock Problem - good results, some possible bugs?
On Tue, 2003-12-09 at 06:31, Jaroslav Kysela wrote: > On Tue, 9 Dec 2003, Mark Knecht wrote: > > Then how do we explain that in dxs_support=2 my sound is so bad? I'm > > using 44.1KHz material and supposedly everything is running at 44.1KHz. > > To be honest, we don't know at the moment. It seems that our > initialization of the VIA bridge might be broken for some reason and VRA > (variable rate) communication between this bridge and VRA capable AC'97 > codec is not 100% correct. > > Jaroslav > Jaroslav, I can certainly accept that we don't know the answer yet. Without respect to either schedule or priority, is it a goal to understand why this is happening and to eventually get this fixed? I can wait for a solution. The dxs=4 option is certainly working well enough for me right now. (I think!) I just want to know that getting this solution is at least on the TODO list and will be addressed one of these days. Thanks, Mark --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] snd-rme9652 fails
On Thu, 2003-12-18 at 14:52, Martin Langer wrote:
> On Thu, Dec 18, 2003 at 12:01:24PM -0800, Fernando Pablo Lopez-Lezcano wrote:
> > > > I confirm this fact:
> > > > with kernel 2.4.23 and alsa 1.0rc2, the module snd-rme9652 can't be loaded
> > > > althought the "old" rme digi 9652 is perfectly working with alsa 0.9.6
> > >
> > > I have found after a lot of printk that if I comment lines 1645 to 1648
> > > of rme9652.c, the driver could be load and I can play music with jMax ;)
> > >
> > > Here are the part to comment:
> > > if (rme9652->ss_channels == RME9652_NCHANNELS)
> > > if ((err = snd_ctl_add(card, kctl = snd_ctl_new1(&snd_rme9652_adat3_check,
> > > rme9652))) < 0)
> > > return err;
> >
> > Did you by any chance printk what is the value of ss_channels? So that
> > the error can be corrected?
> >
>
> I don't have that hardware and I'm not absolutely sure here
> - but it looks like a bug for me.
>
> martin
>
>
> --- rme9652.c.ORIGINALThu Dec 18 23:43:36 2003
> +++ rme9652.c Thu Dec 18 23:45:12 2003
> @@ -1618,7 +1618,6 @@
> RME9652_SPDIF_RATE("IEC958 Sample Rate", 0),
> RME9652_ADAT_SYNC("ADAT1 Sync Check", 0, 0),
> RME9652_ADAT_SYNC("ADAT2 Sync Check", 0, 1),
> -RME9652_ADAT_SYNC("ADAT3 Sync Check", 0, 2),
> RME9652_TC_VALID("Timecode Valid", 0),
> RME9652_PASSTHRU("Passthru", 0)
> };
>
Hi,
I have a Hammerfall Light (the 9636, not the 9652) and the rme9652
driver is loading fine for me. I am getting sound, but only after a
small struggle.
For some reason it appears that the numbering of the audio ports has
changed. I am very sure that the order used to be ADAT1 on inputs 1-8 in
Jack, ADAT2 on inputs 9-16, and I suppose spdif was on 17-18 although
I've never used it.
I haven't used Linux audio on this box since I upgraded to
Alsa-1.0.0rc2 last weekend. It's dual boot and the machine has been in
GigaStudio and Reaktor since then. Anyway, tonight I find the ADAT2 is
coming in on Jack ports 11-18 instead of 9-16.
Has someone intentionally renumbered where audio should be?
Mark
---
This SF.net email is sponsored by: IBM Linux Tutorials.
Become an expert in LINUX or just sharpen your skills. Sign up for IBM's
Free Linux Tutorials. Learn everything from the bash shell to sys admin.
Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] snd-rme9652 fails
On Thu, 2003-12-18 at 19:02, Mark Knecht wrote: >Has someone intentionally renumbered where audio should be? > > Mark > Is anyone addressing this? --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Why does Alsa sometimes not find the HDSP 9652?
Wizard root # /etc/init.d/alsasound start * Loading ALSA drivers... * Loading: snd-seq-oss * Loading: snd-pcm-oss * Loading: snd-mixer-oss * Loading: snd-via82xx * Loading: snd-hdsp /lib/modules/2.4.20-gentoo-r9/kernel/sound/pci/rme9652/snd-hdsp.o: init_module: No such device Hint: insmod errors can be caused by incorrect module parameters, including inva lid IO or IRQ parameters. You may find more information in syslog or the output from dmesg /lib/modules/2.4.20-gentoo-r9/kernel/sound/pci/rme9652/snd-hdsp.o: insmod /lib/m odules/2.4.20-gentoo-r9/kernel/sound/pci/rme9652/snd-hdsp.o failed /lib/modules/2.4.20-gentoo-r9/kernel/sound/pci/rme9652/snd-hdsp.o: insmod snd-hd sp failed * Loading: snd-usb-audio * Loading: snd-seq-oss * Running card-dependent scripts * Restoring Mixer Levels [ ok ] Wizard root # lspci 00:0e.0 Multimedia audio controller: Xilinx Corporation RME Hammerfall DSP (rev 65) Wizard root # --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Why does Alsa sometimes not find the HDSP 9652?
Justin, Hi. Thanks. syslog from that series of boots is attached. Note the first boot, line 304 looks like this: Dec 20 05:43:46 Wizard kernel: ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:807: wait for FIFO status <= 0 failed after 100 iterations Dec 20 05:43:46 Wizard kernel: RME Hammerfall-DSP: no cards found but I didn't use sound that early in the morning, so I didn;t notice the problem. Later in the morning I finally started to kick off some work, but hdspmixer wouldn't load (line 382 or so...) and so I did a reboot. (line 414) This time the lines above did not repeat and I get a better message: (line 716) Dec 20 08:22:48 Wizard kernel: ALSA ../../alsa-kernel/pci/rme9652/hdsp.c:5061: Firmware already loaded, initializing card. If you wanted to look for other, similar, flaky aspects of Linux, my USB UPS does similar thins. Sometimes drivers load, sometimes I have to reboot to get them loaded. There is no pattern. This morning's cold boot worked jsut fine. I got both the HDSP and the UPS. I'm not clear about how to mess with the memory allocator, but I'm not sure that's appropriate after viewing the attached file. Thanks for your help! Mark On Sun, 2003-12-21 at 07:21, Justin Cormack wrote: > On Sat, 2003-12-20 at 16:21, Mark Knecht wrote: > > Wizard root # /etc/init.d/alsasound start > > * Loading ALSA drivers... > > * Loading: snd-seq-oss > > * Loading: snd-pcm-oss > > * Loading: snd-mixer-oss > > * Loading: snd-via82xx > > * Loading: snd-hdsp > > /lib/modules/2.4.20-gentoo-r9/kernel/sound/pci/rme9652/snd-hdsp.o: > > init_module: > > No such device > > Hint: insmod errors can be caused by incorrect module parameters, > > including inva > > lid IO or IRQ parameters. > > You may find more information in syslog or the output from dmesg > > You may indeed find more information in the syslog. > > Probably the memory allocator has failed to load. You need to load it as > early as possible after boot. Might be worth moving sound start to > earlier in boot. > > It might be something else, but without syslog cant help. > > Justin > > > > > --- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > ___ > Alsa-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/alsa-devel syslog.0.bz2 Description: application/bzip
Re: [Alsa-devel] Why does Alsa sometimes not find the HDSP 9652?
Justin, I'm running Alsa-1.0.0rc2. How much more up to date could I be? Also, this is an HDSP 9652 which has the firmware on the board. Why is a firmware loader required at all? Possibly you're on to something I don't see yet? Maybe something is left over from an older version and causing problems? Let me know, Mark On Sun, 2003-12-21 at 09:11, Justin Cormack wrote: > On Sun, 2003-12-21 at 16:03, Mark Knecht wrote: > > Justin, > >Hi. Thanks. syslog from that series of boots is attached. > > > > Note the first boot, line 304 looks like this: > > > > Dec 20 05:43:46 Wizard kernel: ALSA > > ../../alsa-kernel/pci/rme9652/hdsp.c:807: wait for FIFO status <= 0 > > failed after 100 iterations > > Dec 20 05:43:46 Wizard kernel: RME Hammerfall-DSP: no cards found > > ah. Update your alsa to the latest version. This is the old firmware > loader bug. It is fixed now (but there is a seperate loader hdsploader > that you have to run). > > Justin > > --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] snd-rme9652 fails
On Mon, 2003-12-22 at 04:43, Jaroslav Kysela wrote: > > how did this code imply a duplicate control? removing it is > > *wrong*, utterly wrong. it is an important control for some purposes. > > It seems that this control is available only for 9652 not for 9632 > version. The same control was used and defined twice for 9652 while with > 9632 was probably useless: > 9632 or 9636? Doesn't the 9632 use a different driver? (snd-hdsp?) I reported a bug long ago about the /proc file system for the Hammerfall Light (9636) showing ADAT3 for sync instead of spdif. Maybe this is related? --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Why does Alsa sometimes not find the HDSP 9652?
On Mon, 2003-12-22 at 07:30, Paul Davis wrote: > >Justin, > > I'm running Alsa-1.0.0rc2. How much more up to date could I be? > > > > Also, this is an HDSP 9652 which has the firmware on the board. Why > >is a firmware loader required at all? > > its not. jaroslav used that phrase because the bug manifested itself > most clearly when loading firmware. it was a bit more general than > that however, since it affected interactions with the card in several > places. > > --p Paul, Did I miss a response somehow? I haven't received anything on this from Jaroslav. Can you offer any insight into the root cause of this problem? Why should lspci be able to see the card, but Alsa cannot start the driver? (going back tot he original post.) Thanks, Mark --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Why does Alsa sometimes not find the HDSP 9652? - SOLVED
Hi Justin, It looks like I solved this problem in the last few days. The issue appears to driven by how Alsa, or possibly the snd-hdsp driver specifically, attempts to discover the HDSP 9652, and the fact that my machine is moderately fast. I think this is a bug, or at least an opportunity to allow for some boot time tuning in Alsa somewhere, and I've reported it to Thomas privately. On my machine, and Athlon XP 2600+, I use System Commander 7 to partition the drives and to boot to DOS or Linux, and then grub to boot the Linux kernel I'm interested in. Currently SC7 has a timeout value of 20 seconds and grub has a time out value of 8 seconds. What I've found is that if I boot the machine and do not speed up the boot by hitting enter in either of these programs, then Alsa finds the HDSP 9652 100% of the time. However, if I boot but hit enter as early as possible in both programs then Alsa misses the HDSP 9652 100% of the time. So, the answer is just giving the machine enough time before starting the Alsa discovery processes. Owing to my hardware background and use of FPGA's in other areas, the Xilinx FPGA on the HDSP 9652 uses an outboard Flash chip to hold it's configuration code. (Sometimes called firmware here, but not really firmware.) This data is read out of the Flash chip in a fairly slow serial bitstream and takes some time. My suspicion is that by hitting the enter key twice I get to the Alsa boot stage too early, the configuration code is not loaded, and the driver cannot find the card even after 100 tries. If I don't hit enter, the configuration operation gets the extra 28 seconds and that is more than enough time to load the config code before the Alsa driver looks for the card. I've never been comfortable with the message 'failed after 100 iterations'. To me this is not a good way to look for hardware since as machines speed up the amount of time you are giving gets shorter, so possibly Thomas will address this sometime in the future. Until then I'll just look for the smallest value I can make the boot time and still get the card to be recognized. I hope this helps someone in the future not have this problem. Thanks for your help. Cheers, Mark > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Mark Knecht > Sent: Sunday, December 21, 2003 9:14 AM > To: Justin Cormack > Cc: Alsa-Devel > Subject: Re: [Alsa-devel] Why does Alsa sometimes not find the HDSP > 9652? > > > Justin, >I'm running Alsa-1.0.0rc2. How much more up to date could I be? > >Also, this is an HDSP 9652 which has the firmware on the board. Why > is a firmware loader required at all? > >Possibly you're on to something I don't see yet? Maybe something is > left over from an older version and causing problems? > > Let me know, > Mark > > On Sun, 2003-12-21 at 09:11, Justin Cormack wrote: > > On Sun, 2003-12-21 at 16:03, Mark Knecht wrote: > > > Justin, > > >Hi. Thanks. syslog from that series of boots is attached. > > > > > > Note the first boot, line 304 looks like this: > > > > > > Dec 20 05:43:46 Wizard kernel: ALSA > > > ../../alsa-kernel/pci/rme9652/hdsp.c:807: wait for FIFO status <= 0 > > > failed after 100 iterations > > > Dec 20 05:43:46 Wizard kernel: RME Hammerfall-DSP: no cards found > > > > ah. Update your alsa to the latest version. This is the old firmware > > loader bug. It is fixed now (but there is a seperate loader hdsploader > > that you have to run). > > > > Justin > > > > > > > > --- > This SF.net email is sponsored by: IBM Linux Tutorials. > Become an expert in LINUX or just sharpen your skills. Sign up for IBM's > Free Linux Tutorials. Learn everything from the bash shell to sys admin. > Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click > ___ > Alsa-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/alsa-devel > > --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] Why does Alsa sometimes not find the HDSP 9652? -SOLVED
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Justin > Cormack > Sent: Monday, December 29, 2003 10:50 AM > To: Mark Knecht > Cc: alsa list > Subject: RE: [Alsa-devel] Why does Alsa sometimes not find the HDSP > 9652? -SOLVED > > > Ah. that explains why I have never seen it - I always let my machines > boot up from grub on the full timeout and most of them have pretty slow > bootup processes. It is probably best to retry for 1 minute or so in > module init to allow for very fast boots (after all the pci id has > matched, so only broken hardware will never succeed). > > Justin > Sure. I was thinking that the snd-hdsp driver could also have a config option that specified how long I wanted it to wait and keep trying. If I set if for 30 seconds, then I don't need abnormally long timeouts in SC7 or grub, but if I forget and hit enter one morning early then the driver could just sit there and work for whatever amount of time I told it to. Anyway, I think that a couple of other people have seen things like this before, so now I'll play a bit with minimum timeouts and probably end up with a reasonable boot time but still 100% functionality. Now, if I could only get someone to pay attention to the new problems in the older Hammerfall 9636 driver... Cheers, Mark --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Alsa-1.0.0rc2 Hammerfall Light - small bug report
On Fri, 2004-01-02 at 06:10, Martin Langer wrote: > On Sat, Dec 06, 2003 at 06:15:19PM -0800, Mark Knecht wrote: > > > > Note ADAT3 which do not exist on > > this card. > > > > > > [EMAIL PROTECTED] mark]$ cat /proc/asound/card0/rme9652 > [...] > > ADAT Sample rate: 44100Hz > > ADAT1: No Lock > > ADAT2: No Lock > > ADAT3: No Lock > > > > This patch will remove the ADAT3 entry for light users. Please try it out, > because I don't have any hammerfall hardware. > > > martin Martin, Sorry, but I cannot try it out. My Hammerfall Light box is a PlanetCCRMA machine which is RPM based. I wouldn't have a clue how to patch an RPM to do this. Sorry, Mark --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] sbLive! -Drive digital IOs exchanged?
On Mon, 2004-01-05 at 08:57, Takashi Iwai wrote: > At Wed, 24 Dec 2003 22:20:57 +0100, > Eckhard Jokisch wrote: > > > > Hello guys, > > I just noticed that the controls ( or their names) of the digital inputs of > > Live!-drive are changed. If I want ot get sound out of the coaxial inputs I > > have to raise the optocal s "sliders" in alsamixer as well as in > > alsermixergui. > > i don't see any changes of codes regarding this... > is only the capture switch swapped? > (to be sure, do you mean "IEC958 Optical Capture" and "IEC958 Coax > Capture", right?) > > > Takashi > Recently the I/O's of the Hammerfall Light also changed: Old playback_1-8 -> ADAT1 playback_9_16 -> ADAT2 playback_17-18 -> spdif (I suppose) Now playback_3-10 -> ADAT1 playback_11-18 -> ADAT2 playback_1-2 -> spdif (I suppose) --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id=1278&alloc_id=3371&op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Compiling but not installing Alsa
Hi, I did my first Alsa CVS download this morning just to take a look at the code. I am a PlanetCCRMA user, but wanted to know more about Alsa. I have not yet found a README or INSTALL file on how to do a build. Are there any written instructions in the CVS tree? I looked at the Makefile, which I can't read well, and I get the feeling that the default operation would be to build AND install the code. As a RPM based user I would like to build the code, but not install it until the Planet updates the appropriate RPM. Is this possible with the current CVS code? Thanks, Mark --- 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
[Alsa-devel] PCI_DEVICE_ID_XILINX_HAMMERFALL_DSP
Hi,
Where are the definitions for PCI_DEVICE_ID_XILINX_HAMMERFALL_DSP and
PCI_VENDOR_ID_XILINX kept in the alsa code?
Thanks,
Mark
static struct pci_device_id snd_hdsp_ids[] __devinitdata = {
{
.vendor= PCI_VENDOR_ID_XILINX,
.device= PCI_DEVICE_ID_XILINX_HAMMERFALL_DSP,
.subvendor = PCI_ANY_ID,
.subdevice = PCI_ANY_ID,
}, /* RME Hammerfall-DSP */
{ 0, },
};
---
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: [Alsa-devel] PCI_DEVICE_ID_XILINX_HAMMERFALL_DSP
Thanks Paul.
I'm still struggling with getting this new card going. Fernanado and I
are working through the issues one at a time by doing a Planet RPM for
the newest version alsa and have applied the one line patch that you
pointed me at the other day. However, I'm still not running.
1) Fernando applied the one line patch applied:
--- hdsp.c-orig 2002-12-03 19:28:40.0 +
+++ hdsp.c 2002-12-03 19:28:06.0 +
@@ -2966,6 +2966,7 @@
switch (rev & 0xff) {
case 0xa:
+ case 0x64:
/* hdsp_initialize_firmware() will reset this */
hdsp->card_name = "RME Hammerfall DSP";
break;
2) Alsaconf works, sort of. modules.conf gets built, but my machine will
not reboot after running it. Don't know why.
3) When I boot I see the following message in /var/log/messages
Dec 9 12:39:40 Godzilla kernel: Hammerfall memory allocator: buffers
allocated for 1 cards
Dec 9 12:39:40 Godzilla kernel: RME Hammerfall-DSP: no cards found
Dec 9 12:39:40 Godzilla insmod:
/lib/modules/2.4.19-1.ll/kernel/drivers/sound/pci/rme9652/snd-hdsp.o:
init_module: No such device
4) lspci -v shows the card is there:
00:0f.0 Multimedia audio controller: Xilinx, Inc.: Unknown device 3fc5
(rev 64)
Flags: bus master, medium devsel, latency 32, IRQ 10
Memory at f600 (32-bit, non-prefetchable) [size=64K]
I'm completely puzzled. What are we doing wrong?
Thanks,
Mark
On Mon, 2002-12-09 at 20:11, Paul Davis wrote:
> > Where are the definitions for PCI_DEVICE_ID_XILINX_HAMMERFALL_DSP and
> >PCI_VENDOR_ID_XILINX kept in the alsa code?
>
> one of two places. either in the kernel source (if you have a much,
> much newer kernel (2.5)) or at the top of either rme9652.c or hdsp.c
> (there are conditional #define's there to check if they are already
> defined in the kernel's PCI ID header.
>
> --p
---
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: [Alsa-devel] PCI_DEVICE_ID_XILINX_HAMMERFALL_DSP
We will recheck. I have immense faith in Fernando, but everyone makes mistakes. On Mon, 2002-12-09 at 21:12, Paul Davis wrote: > >3) When I boot I see the following message in /var/log/messages > > > >Dec 9 12:39:40 Godzilla kernel: Hammerfall memory allocator: buffers > >allocated for 1 cards > >Dec 9 12:39:40 Godzilla kernel: RME Hammerfall-DSP: no cards found > >Dec 9 12:39:40 Godzilla insmod: > >/lib/modules/2.4.19-1.ll/kernel/drivers/sound/pci/rme9652/snd-hdsp.o: > >init_module: No such device > > are you sure you have the new module installed? i know of at least 2 > people using the patch you have used that have got their new 9652's working. > > --p > --- 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
[Alsa-devel] HDSP 9652 - a couple of small (?) issues
Hi, I'm finding that I seem to have two problems with this new card: 1) I am unable to turn down the volume with alsamixer. All the way up or down, the volume is always very loud. Has anyone else seen this? Is there some other tool which will actually control the volume? 2) If I use alsamixer and set volume bars and then use 'alsactl store' to store the levels, if I use 'alsactl restore' the restore process always sets channel 0 back to 0. Other channels are restored at their saved levels. Is alsactl the right tool to use to accomplish this? I'm not at all clear who to report this to. Who works on alsactl and alsamixer? Thanks, Mark --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] HDSP 9652 - a couple of small (?) issues
Paul, Thanks. We new users will certainly appreciate that. I notice I get a message "IO box is a DigiFace" in dmesg. Is the mixer in DigiFace working, or is there some possibility that there's a clue there? Thanks much, Mark On Wed, 2002-12-11 at 05:38, Paul Davis wrote: > >1) I am unable to turn down the volume with alsamixer. All the way up or > >down, the volume is always very loud. Has anyone else seen this? Is > >there some other tool which will actually control the volume? > > the mixer is (currently) disabled on the 9652-hdsp. i have asked RME > to send me the commands to reset it and the new register information > on how to access it (its not the same as the regular hdsp). i will > prod them again this morning. > > --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
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
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 > > > > > > > > > > > > > > > -
Re: alsasound init script (Re: [Alsa-devel] possible problems withrc6 aplay )
On Mon, 2002-12-16 at 07:23, Paul Davis wrote: > >> that reminds me. the last version of the alsasound script that i saw > >> did something very dangerous. it seemed to try to install *every* > >> snd-card module it could find. if you have a system with an ISA bus, > >> this can prove fatal to the system - many ISA device probes will kill > >> the machine if the device is not present. > > > >well, you can find that the alsasound script tries to load the modules > >aliased as "snd-card-[0-9]", not the all snd-card-* modules. > >remember that there is no module named as such. that means, if such a > >module is found, it was certainly configured by some means. > > ah. sorry, i missed the -c on modprobe. i take it all back :( > > --p I wonder if this could have anything to do with a different problem I'm seeing. I have a HDSP 9652 and a MidiMan 2X2 interface. The HDSP is installed by alsaconf. The 2X2 is installed usign Fernando's instructions from the Planet. When I do a cold boot, the HDSP is always recognized first, and then the MidiMan comes up as card 2, at least by reading the numbers of the devices in /dev/snd. However, if I reboot, many times the system makes the 2X2 card 1 and the HDSP card 2, and that breaks a lot of this software. What would cause this to happen and how could I stop it? I have found that everything seems to work fine if I remember to unplug the 2X2 when the reboot begins, but sometimes I don't remember and have to go through one more boot cycle. Cheers, Mark --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ 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: [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: alsasound init script (Re: [Alsa-devel] possible problems withrc6 aplay )
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 Thanks, Mark --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: alsasound init script (Re: [Alsa-devel] possibleproblems with rc6 aplay )
On Wed, 2002-12-18 at 03:17, Takashi Iwai wrote: > At Wed, 18 Dec 2002 11:46:45 +0100, > I wrote: > > > > > It would be better to make the alsasound script more robust (and > > > independent of the startup order) and able to deal with partially loaded > > > modules, so instead of just checking for the /proc/asound directory it > > > would actually see what modules are already loaded and only load those > > > that are not. It does not look too easy, it seems that /proc/asound does > > > not provide a list of loaded modules (rather a list of cards that are > > > not associated with module names). > > > > agreed. a scenario i can imagine now is that the script just takes a > > look at /proc/asound/cards and checks the numbers at the first column. > > this should correspond to the card indices which have been already > > loaded. then the script will try to load the modules snd-card-X but > > skip the numbers listed in the above... > > i'll try to rewrite as this way. > > after reconsideration: it would be much simpler to create a new proc > file which shows the modules already loaded. > I was wondering what would happen in this process if someone had two r three identical USB devices, like the MidiMan 2X2? OR also two identical cards like the RME HDSP 9652? It is important that the system recognize the same hardware as the same sound device every time the machine booted, and whether the machine is warm or cold booted. The name I'm seeing linked in /dev/sound are possibly a bit too generic, being just '2X2' and 'DSP'. Just a thought. --- This sf.net email is sponsored by: With Great Power, Comes Great Responsibility Learn to use your power at OSDN's High Performance Computing Channel http://hpc.devchannel.org/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] alsaplayer not working with alsa?
Hi, When running alsaplayer version 0.99.73 without jack, I'm seeing this failure: [mark@Godzilla mark]$ alsaplayer -v alsaplayer 0.99.73 [mark@Godzilla mark]$ alsaplayer alsaplayer: pcm.c:6293: snd_pcm_unlink_ptr: Assertion `0' failed. AlsaPlayer interrupted by signal 6 [mark@Godzilla mark]$ alsaplayer works very well when jack is running. Anyone else seeing this? Thanks, Mark --- 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: [linux-audio-user] Re: [Alsa-devel] alsaplayer not working withalsa?
Thanks Steve. Merry Xmas! On Mon, 2002-12-23 at 05:34, Steve Harris wrote: > On Sun, Dec 22, 2002 at 01:19:05 -0800, Mark Knecht wrote: > > [mark@Godzilla mark]$ alsaplayer > > alsaplayer: pcm.c:6293: snd_pcm_unlink_ptr: Assertion `0' failed. > > AlsaPlayer interrupted by signal 6 > > [mark@Godzilla mark]$ > > > >alsaplayer works very well when jack is running. > > > >Anyone else seeing this? > > Yes. > > I suspect that Fernando needs to update alsaplayer. > > - Steve --- 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: [linux-audio-user] Re: [Alsa-devel] alsaplayer not workingwith alsa?
No, just standard Intel hardware... On Mon, 2002-12-23 at 06:05, Takashi Iwai wrote: > Hi, > > if you're using a ppc snd-powermac driver, then it's likely a > long-standing bug of alsa-lib (somehwere deep inside). it appears > only on ppc with alsaplayer. the maintainer is me, but, sorry, atm i > haven't had a hardware for debugging this... > > have a merry christmas! > > > Takashi > > At 23 Dec 2002 05:46:45 -0800, > Mark Knecht wrote: > > > > Thanks Steve. Merry Xmas! > > > > On Mon, 2002-12-23 at 05:34, Steve Harris wrote: > > > On Sun, Dec 22, 2002 at 01:19:05 -0800, Mark Knecht wrote: > > > > [mark@Godzilla mark]$ alsaplayer > > > > alsaplayer: pcm.c:6293: snd_pcm_unlink_ptr: Assertion `0' failed. > > > > AlsaPlayer interrupted by signal 6 > > > > [mark@Godzilla mark]$ > > > > > > > >alsaplayer works very well when jack is running. > > > > > > > >Anyone else seeing this? > > > > > > Yes. > > > > > > I suspect that Fernando needs to update alsaplayer. > > > > > > - Steve > > > > > > > > > > --- > > 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 > > > > > --- > 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 --- 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: [linux-audio-user] Re: [Alsa-devel] alsaplayer notworking with alsa?
Takashi-san,
I am attaching my current asound.state file. The installed card is an
RME HDSP 9652, their new card. My current modules.conf looks like:
alias parport_lowlevel parport_pc
alias eth0 eepro100
alias usb-controller usb-uhci
# --- 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=3 device_mode=0666
options snd-hdsp index=0
options snd-usb-audio index=1
# --- END: Generated by ALSACONF, do not edit. ---
# -- Keep modules from being autocleaned
add options -k snd-card-0
add options -k snd-card-1
The alsaplayer failure when jack is not running looks like:
[mark@Godzilla mark]$ alsaplayer
alsaplayer: pcm.c:6293: snd_pcm_unlink_ptr: Assertion `0' failed.
AlsaPlayer interrupted by signal 6
[mark@Godzilla mark]$
Please let me know if thee is more information you'd like to look at.
Thanks,
Mark
On Tue, 2003-01-07 at 07:58, Takashi Iwai wrote:
> At 27 Dec 2002 14:56:22 -0800,
> Mark Knecht wrote:
> >
> > No, just standard Intel hardware...
>
> well, then you have an exotic one :)
>
> could you show /etc/asound.state?
> perhaps the card lacks of some mixer controls which are required.
>
>
> thanks,
>
> Takashi
state.DSP {
control.1 {
comment.access 'read write'
comment.type IEC958
iface PCM
name 'IEC958 Playback Default'
value
''
}
control.2 {
comment.access 'read write inactive'
comment.type IEC958
iface PCM
name 'IEC958 Playback PCM Stream'
value
''
}
control.3 {
comment.access read
comment.type IEC958
iface MIXER
name 'IEC958 Playback Con Mask'
value
'3b00'
}
control.4 {
comment.access read
comment.type IEC958
iface MIXER
name 'IEC958 Playback Pro Mask'
value
'1f00'
}
control.5 {
comment.access 'read write'
comment.type INTEGER
comment.range '0 - 65536 (step 1)'
iface PCM
name Mixer
value.0 0
value.1 0
value.2 0
}
control.6 {
comment.access 'read write'
comment.type ENUMERATED
comment.item.0 ADAT1
comment.item.1 Coaxial
comment.item.2 Internal
iface PCM
name 'IEC958 Input Connector'
value Internal
}
control.7 {
comment.access 'read write'
comment.type BOOLEAN
iface PCM
name 'IEC958 Output also on ADAT1'
value false
}
control.8 {
comment.access 'read write'
comment.type ENUMERATED
comment.item.0 Internal
Re: [Alsa-devel] Re: HDSP 9652 MIDI - A timing disaster?
On Mon, 2003-01-13 at 09:04, Clemens Ladisch wrote: > Mark Knecht wrote: > >I recently purchased an RME HDSP 9652 card. The card is working fine > > for audio, but the MIDI interface is a timing disaster. The interface > > works, but won't keep time. A 2 minute song is Rosegarden takes abut > > 2:45 to play every time. You can hear how the HDSP isn't delivering > > closely spaced MIDI events together, but is sort of smearing them out. > > The hdsp driver doesn't send more than one MIDI byte per timer tick. > IMHO it should be modified to send in a loop until the FIFO is full > (however, I don't know if the HDSP has a FIFO at all). And it should start > sending in output_trigger() instead of delaying it to the next timer tick. > Clemens, Thanks for the response. One comment I forgot to make in the first post. This MIDI interface works fine under Windows, so whatever causes the problem is purely a Alsa MIDI issue. If we can figure it out, then we can fix it. I agree that it sounds like this sort of one note per timer tick. When the interface is supposed to send a chord, it sends what sounds like an arpegiated chord. It's all smeared out. Is there some example code I could look at to understand implementing a FIFO? However, if there is a FIFO Full indication, doesn't we need to know _how_ it's indicated? I would assume it's different for all cards? (Bus possibly similar for cards from the same manufacturer? Also, this is the HDSP 9652, which is a single PCI card. Is this problem showing up for the DigiFace/MultiFace type cards? Thanks, Mark --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] patch #1 for hdsp MIDI
Paul,
Thanks for looking onto this. We'll try to get it into the Alsa RPM
and tested soon.
Cheers,
Mark
On Mon, 2003-01-13 at 13:34, Paul Davis wrote:
> Index: hdsp.c
> ===
> RCS file: /cvsroot/alsa/alsa-kernel/pci/rme9652/hdsp.c,v
> retrieving revision 1.16
> diff -u -u -r1.16 hdsp.c
> --- hdsp.c 7 Jan 2003 10:36:32 - 1.16
> +++ hdsp.c 13 Jan 2003 13:32:32 -
> @@ -817,10 +817,18 @@
>
> static inline int snd_hdsp_midi_output_possible (hdsp_t *hdsp, int id)
> {
> + int fifo_bytes_used;
> +
> if (id) {
> - return (hdsp_read(hdsp, HDSP_midiStatusOut1) & 0xff) < 128;
> + fifo_bytes_used = hdsp_read(hdsp, HDSP_midiStatusOut1) & 0xff;
> } else {
> - return (hdsp_read(hdsp, HDSP_midiStatusOut0) & 0xff)< 128;
> + fifo_bytes_used = hdsp_read(hdsp, HDSP_midiStatusOut0) & 0xff;
> + }
> +
> + if (fifo_bytes_used < 128) {
> + return 128 - fifo_bytes_used;
> + } else {
> + return 0;
> }
> }
>
>
> ---
> This SF.NET email is sponsored by: FREE SSL Guide from Thawte
> are you planning your Web Server Security? Click here to get a FREE
> Thawte SSL guide and find the answers to all your SSL security issues.
> http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
> ___
> Alsa-devel mailing list
> [EMAIL PROTECTED]
> https://lists.sourceforge.net/lists/listinfo/alsa-devel
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
On Sun, 2003-01-19 at 16:07, Thomas Charbonnel wrote: > > So the "numid=5 26,26,16384" line says: > connect software output 1 (called "playback" in the above table) to line > out left, as the syntax of the call is input_source,output_source,value. > Thomas, I have possibly more than a passing interest in this subject as I use the HDSP 9652 card that Patrick mentioned and find this whole amixer language completely unfathomable. In your quote above, could you outline what each parameter stands for? "numid=5 26,26,16384" numid=5 - Is this a physical connection? A mixer input or output? An abstract number just used to keep track of things? 26,26 - clearly Patrick and I were thinking that these two numbers related to specific hardware inputs and outputs, but apparently not. 16384 - a mixer volume? Thanks in advance for helping. Cheers, Mark --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] amixer question - numid=2
Hi, On my HDSP 9652 system executing the command amixer controls yields a list that appears to be 166 items long, starting with numid=1 and ending with numid=166. However, closer study shows numid=2 seems to be missing. Is this an issue with amixer or my card? What function might normally be associated with numid=2? Thanks, Mark --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
On Sun, 2003-01-19 at 17:00, Roger Williams wrote: > > Patrick Shirkey <[EMAIL PROTECTED]> writes: > > > Can we route multiple software outputs to the same hardware output? > > Yes. For instance, when recording 8 tracks, I'll generate a monitor > mix (for JACK's outputs) to outputs 1 & 2 like this: > > amixer cset numid=5 26,26,16384 > amixer cset numid=5 28,26,16384 > amixer cset numid=5 30,26,16384 > amixer cset numid=5 32,26,16384 > amixer cset numid=5 27,27,16384 > amixer cset numid=5 29,27,16384 > amixer cset numid=5 31,27,16384 > amixer cset numid=5 33,27,16384 > > -- Roger, OK, I just don't get it yet. This is from the Alsa page on the HDSP cards: * Since the Multiface only have 18 i/o channels, the channel mapping in the matrix mixer is different from the Digiface when operating at 48kHz or lower. [Ed. This is a routing table] input_source: 0-7 (analog), 16-23 (adat), 24-25 (spdif), 26-51 (playback) output_source: 0-7 (analog), 16-23 (adat) 24-25 (spdif), 26-27 (line out) * In your example above, is the use of 26 and 27 on the output part of the command telling the hardware to route whatever it is that you're mixing to the line out connectors on your box? Second, where do the inputs numbered 26-33 come from. I can't figure this part out. Are they outputs from the HDSP hardware mixer? Or do they mean from physical inputs? (somehow renumbered) This is the part I don't get right now. I presume that your use of 16384 is to reduce volume so that after summing 4 channels you do not create output clipping if all the inputs hit maximum volume at the same time? QUESTION - If you wanted to route input 0 directly to an output, could you use a command like: amixer cset numid=5 0,26,16384 amixer cset numid=5 1,27,16384 I think my HDSP 9652 will have different numbering since I have a different number of I/O's on the card, but I want to understand your example since it seems like a good one. Thanks, Mark --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Roger, This is very, very helpful. Thanks for sharing this info. I am trying to do similar things with the HDSP 9652, which is similar but a bit different, I'd like to address a couple more things. (Darn...Tennessee just scored!) :-((( 7-7 I just want to clearly understand the physical I/O numbering right now. Once I've got that I'll ask you a couple of questions about the mixer if I may. OK, it appears that the MultiFace has a slightly different numbering system for your analog channels, starting with 0-7 instead of what I think I have which starts with 1-8. Is this correct? If I look at the HDSP amixer info, I seem to start with an index of 1, not 0. Am I looking at the right stuff? (I've done some sorting to make this more readable to me. I have this initial section with 9 controls, and then 26 sections that are identical to the second area I show below, indexing from 1-26. I presume that your first one would start with index=0? [mark@Godzilla mark]$ amixer controls numid=1,iface=PCM,name='IEC958 Playback Default' numid=3,iface=MIXER,name='IEC958 Playback Con Mask' numid=4,iface=MIXER,name='IEC958 Playback Pro Mask' numid=5,iface=PCM,name='Mixer' numid=6,iface=PCM,name='IEC958 Input Connector' numid=7,iface=PCM,name='IEC958 Output also on ADAT1' numid=8,iface=PCM,name='Preferred Sync Source' numid=9,iface=PCM,name='Passthru' numid=10,iface=PCM,name='Line Out' numid=11,iface=MIXER,name='Chn',index=1 numid=12,iface=PCM,name='Input Peak',index=1 numid=13,iface=PCM,name='Output Peak',index=1 numid=14,iface=PCM,name='Playback Peak',index=1 numid=15,iface=PCM,name='Playback RMS',index=1 numid=16,iface=PCM,name='Input RMS',index=1 On Sun, 2003-01-19 at 22:24, Roger Williams wrote: > >>>>> Mark Knecht <[EMAIL PROTECTED]> writes: > > Second, where do the inputs numbered 26-33 come from. > > As far as the Multiface's analogue I/O goes, channels appear to be > numbered like this: When you say 'appear to be numbered like this', how did you determine this? Was it documented somewhere? Or did you have to test yourself? > > Multiface inputs 1-8 = amixer source channels 0-7 > Multiface outputs 1-8 = amixer destination channels 0-7 > Multiface line (headphone) outputs = amixer destination channels 26-27 > alsa_pcm:playback_1-8 = amixer source channels 26-33 > OK, here's where you throw me. Let me list out what I thought I knew about the MultiFace, and then correct me where I'm wrong please. The MultiFace has 18 inputs - 8 analog, 8 ADAT, 2 s/pdif, and 20 outputs (including the Headphone outs if they are really separate from everything else. They may not be...) so I would have expected you to list: (Yea!!! Raiders score! 14-7) MultiFace analog inputs 1-8 = amixer source channels 0-7 MultiFace ADAT inputs 9-16 = amixer source channels W-X (8-16?) MultiFace s/pdif inputs 17-18 = amixer source channels Y-Z (17-18?) Basically, to use the 18 inputs, they all must have unique numbers. Correct? MultiFace analog outputs 1-8= amixer dest. channels 0-7 MultiFace ADAT outputs 9-16 = amixer dest. channels W-X (8-16?) MultiFace s/pdif outputs 17-18 = amixer dest. channels Y-Z (17-18?) MultiFace Line outputs 1-2 = amixer dest. channels 26-27 Maybe all of the features of the MultiFace not actually supported in the current driver, so you didn't list them, or maybe you just didn't use them, so you didn't write them down? In my case I am guessing that my physical I/O numbering will be as follows: HDSP 9652 ADAT-1 inputs 1-8 = amixer source channels 1-8 HDSP 9652 ADAT-2 inputs 9-16= amixer source channels 8-16 HDSP 9652 ADAT-3 inputs 17-24 = amixer source channels 17-24 HDSP 9652 s/pdif inputs 25-26 = amixer source channels 25-26 and similar numbering for the outputs. Do you think this is right? Any other thoughts or comments? Thanks, Mark --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] hdsp multiface pci.
Roger, I think the light is just starting to turn on, or at least I can only hope... ;-) See if you can help me improve the following description. I can think of my HDSP mixer as a device with 52 inputs and 26 outputs. The inputs look like: 1) 26 mixer inputs come from the HDSP's physical inputs - numbered 0-25 in the mixer - called Alsa_pcm:capture_1 - 26 in Jack 2) 26 mixer inputs come from the Alsa:playback group - numbered 26-51 in the mixer - called Alsa_pcm:playback_1 - 26 in Jack The outputs look like: 1) 26 mixer outputs come from the mixer - numbered 0-25 out of the mixer By default, the HDSP driver then takes the Alsa_pcm:playback group and hooks them to (more or less) matching output destinations: Alsa_pcm:playback_1 -> HDSP Output 0 Alsa_pcm:playback_2 -> HDSP Output 1 ... Alsa_pcm:playback_26 -> HDSP Output 25 so that if I connect capture_1 to playback_1 then whatever comes in on the ADAT-1, channel 0 input will get sent back out on ADAT-1, channel 1 output. To test this idea, and using your headphone mix example, I should be able to create a hardware monitoring setup by routing physical inputs directory to physical outputs using something like this: amixer cset numid=5 0,0,32768 amixer cset numid=5 1,1,32768 ... amixer cset numid=5 25,25,32768 which would route each physical input to each physical output, 1 for 1, at a volume of unity gain. (As per Marcus's notes again.) What is not at all clear yet is whether a single input can go to multiple outs with different gains. For instance, if I execute: amixer cset numid=5 0,0,1 amixer cset numid=5 0,1,3 I am attempting to take physical input 0 and sending it to both the left and right outputs, but at different volumes. Is this legal? I'm not sure. In my case, I use Alsa_pcm:playback_1/2 for my main speakers, and playback_3/4 for my headphones. The problem I've been having is that I didn't know how to set the volume on my speakers with no mixer. Using this information, I could execute: amixer cset numid=5 26,0,3000 amixer cset numid=5 27,1,3000 and now my playback_1/2 should come out of my speakers, but at considerably reduced volumes. I'm going to stop and get feedback, as this is almost making sense. In the meantime, I might as well try the commands above and see if my speaker volume is under control. Thanks very much for your help! Cheers, Mark On Mon, 2003-01-20 at 02:14, Roger Williams wrote: > >>>>> Mark Knecht <[EMAIL PROTECTED]> writes: > > > This is very, very helpful. > > What will be "very, very helpful" will be Thomas's TotalMix clone! :) > > > ... it appears that the MultiFace has a slightly different > > numbering system for your analog channels, starting with 0-7 > > instead of what I think I have which starts with 1-8. > > My "amixer controls" dump looks the same as yours. I don't know what > "index=1" means, but it doesn't appear to mean that our cset indexing > begins at 1. I've got to assume that Paul or Thomas already know > everything there is to know about the HDSP mixer, and I hate to > explore known territory, but when you don't have a map... > > > When you say 'appear to be numbered like this', how did you determine > > this? Was it documented somewhere? Or did you have to test yourself? > > Well, it matches Marcus Andersson's notes on the ALSA HDSP page: > > input_source: 0-7 (analog), 16-23 (adat), 24-25 (spdif), 26-51 (playback) > output_source: 0-7 (analog), 16-23 (adat) 24-25 (spdif), 26-27 (line out) > > I found "output_source" confusing, but it makes sense if I rename it > "destination". > > > The MultiFace has 18 inputs ... so I would have expected you to list: > > Some of the numbering is discontinuous (because the Multiface doesn't > have the Digiface's ADAT2 range of channels), so the full Multiface > I/O list is: > > Inputs to HDSP Mixer > > Multiface analogue inputs 1-8 = amixer source channels 0-7 > Multiface ADAT inputs 1-8 = amixer source channels 16-23 > Multiface SPDIF input = amixer source channels 24-25 > alsa_pcm:playback_1-26 = amixer source channels 26-51 > > Outputs from HDSP Mixer > > Multiface analogue outputs 1-8 = amixer destination channels 0-7 > Multiface ADAT outputs 1-8 = amixer destination channels 16-23 > Multiface SPDIF output = amixer destination channels 24-25 > Multiface line (headphone) output = amixer destination channels 26-27 > > Mapping between Multiface inputs and alsa
Re: [Alsa-devel] hdsp multiface pci.
Roger, First, thanks for taking time to follow this through with me. This has been helpful and I do at least feel like I'm starting to understand what the software is tying to do. When I tried some amixer commands I was disappointed to find that they do nothing at all on my machine. No command I tried seems to control volume to my headphones or speakers at all. I guess the HDSP 9652 is not supported at this time. Makes me feel like I bought the wrong product. Anyway, I will continue to study and understand this stuff and hope that one day some of these features actually work. Thanks for your help! Cheers, Mark On Mon, 2003-01-20 at 06:25, Roger Williams wrote: > >>>>> Mark Knecht <[EMAIL PROTECTED]> writes: > > > I can think of my HDSP mixer as a device with 52 inputs and 26 > > outputs. > > In the case of the 9652, you don't have headphone outputs, so you > don't have the Digiface's 27th and 28th outputs. > > > 1) 26 mixer inputs come from the HDSP's physical inputs > > - numbered 0-25 in the mixer > > - called Alsa_pcm:capture_1 - 26 in Jack > > Yup. > > > 2) 26 mixer inputs come from the Alsa:playback group > > - numbered 26-51 in the mixer > > - called Alsa_pcm:playback_1 - 26 in Jack > > Yup. > > > 1) 26 mixer outputs come from the mixer > > - numbered 0-25 out of the mixer > > Yup. > > > By default, the HDSP driver then takes the Alsa_pcm:playback group > > and hooks them to (more or less) matching output destinations: > > Perhaps, but I'm not sure about that. I always explicitly set up the > HDSP mixer routes. I just removed all of my ALSA modules, removed the > HDSP Cardbus card, power-cycled the Multiface, and reinstalled > everything; and I had to issue an "amixer cset numid=5 26,0,32768" > command to connect alsa_pcm:playback_1 to Multiface output 1. > > > so that if I connect capture_1 to playback_1 then whatever comes > > in on the ADAT-1, channel 0 input will get sent back out on > > ADAT-1, channel 1 output. > > You don't connect capture_1 to playback_1, because playback_1 is a > signal coming from ALSA, going into the HDSP mixer. But you _can_ > connect the signal arriving on the ADAT1:1 input (which _also_ drives > ALSA's capture_1 input) to the ADAT1:1 output with an "amixer cset > numid=5 0,0,32768" command. (But playback_1 isn't routed to the > ADAT1:1 output except by coincidence or a default setting -- playback_1 > doesn't have anything to do with your ADAT1:1 input -> ADAT1:1 output > connection.) > > > amixer cset numid=5 0,0,32768 > > amixer cset numid=5 1,1,32768 > > ... > > amixer cset numid=5 25,25,32768 > > > which would route each physical input to each physical output, 1 > > for 1, at a volume of unity gain. (As per Marcus's notes again.) > > Yup. > > > What is not at all clear yet is whether a single input can go to > > multiple outs with different gains. For instance, if I execute: > > > amixer cset numid=5 0,0,1 > > amixer cset numid=5 0,1,3 > > Sure, that works just fine. I'll run a combined setup like this: > > Monitor submix > == > amixer cset numid=5 0,26,2 > amixer cset numid=5 1,27,2 > amixer cset numid=5 2,26,15000 > amixer cset numid=5 3,27,15000 > amixer cset numid=5 4,26,1 > amixer cset numid=5 5,27,1 > > DAT safety recording > == > amixer cset numid=5 0,24,16384 > amixer cset numid=5 1,25,16384 > amixer cset numid=5 2,24,12288 > amixer cset numid=5 3,25,12288 > amixer cset numid=5 4,24,8192 > amixer cset numid=5 5,25,8192 > > The changes I make in the first group (headphones submix) don't have > any effect on the signal being recorded by the DAT, which is set up in > the second group. > > > I am attempting to take physical input 0 and sending it to both > > the left and right outputs, but at different volumes. Is this > > legal? > > Sure. Consider RME's description of TotalMix, which is "nothing more" > than a software interface (OK, I'm a hardware guy) to the HDSP mixer: > > - setting up delay-free submixes (headphone mixes) > - unlimited routing of inputs and outputs (free utilisation, patchbay function) > - distributing signals to several outputs at a time > - simultaneous playback of different programs over only one stereo channel > - mixing of the input signal to the playback signal (complete AS
RE: [Alsa-devel] hdsp multiface pci.
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Roger > Williams > Sent: Wednesday, January 22, 2003 10:31 AM > To: Paul Davis > Cc: [EMAIL PROTECTED]; [EMAIL PROTECTED] > Subject: Re: [Alsa-devel] hdsp multiface pci. > > > > Paul Davis <[EMAIL PROTECTED]> writes: > > >> This would explain why snd_hdsp works (i.e. you can playback and > >> record through the default I/O), although amixer doesn't do > >> anything: the driver doesn't have to set up any default > >> connections, because those are part of the FPGA reset state... > > > actually, the driver does have to set up default connections, > > which are zero gain for every possible routing... > > Yes, I understand that that's what the driver is _supposed_ to do. > That's how it works on my HDSP PCI and Cardbus systems. But isn't it > true that the current driver doesn't actually set up any of those > zero-gain connections for the HDSP 9652? > > This is the only point that I was trying to make to Mark -- the > default unity-gain connections (i.e. playback -> H/W output) that he > has been using are FPGA configuration defaults, not explicitly set up > by the driver. > Yes, and I think I understood that this was probably what was happening as our conversation progressed. When I made that statement it was a bit earlier on, if I remember correctly, and I was explaining my 'vision' of what I thought was going on. That should not be confused with the trusth! ;-) It makes perfect sense that the RME card itself has some default connections. Thanks, Mark --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] HDSP 9652 MIDI Timing - Much improved, but no Port 1...
Paul, Takashi-san and Clemens, Hi. A couple of days ago Fernando got a new RPM built for Alsa which includes the recent HDSP 9652 MIDI timing fix that you worked together on and supplied about 10 days ago. I wanted to report back that the timing is now much improved. I haven't used it a lot yet, but I am playing moderately complicated songs now and the timing seems fine. Thanks. There is one problem that has come up new in this release. The HDSP 9652 has two MIDI ports. With this release I can only get MIDI out on Port 2. I cannot get MIDI out at all on Port 1. Both ports used to work on the previous version, albeit with bad timing, so this fix this has changed this aspect of the driver. I also tried using kaconnect to look at the connections between Rosegarden and the alsa_sequencer. It shows that Rosegarden is hooked to 64:32 External MIDI 0 only. A second group, 64:0 External MIDI 0 shows up, but kaconnect will not connect to it. I do not know what that means, but it seems to be part of it. It strikes me that I have not done any recording with this device, so I should do some of that before we make any more driver changes. However, I wanted to report back a big thanks for a step in the right direction, even if we are not quite all the way there yet and allow you to look at what might be causing this problem. If there is any specific testing you'd like me to do, please let me know and I'll try to get to it as soon as possible. I'd like to get this card fully supported (yes, the mixer too Paul!) ;-) as I get 2-3 emails a week from people asking me if they should buy the card and I'd like to tell them yes. Thanks much, Mark --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] amixer question - numid=2
Thanks! On Fri, 2003-01-24 at 11:15, Takashi Iwai wrote: > At 19 Jan 2003 10:59:39 +, > Mark Knecht wrote: > > > > Hi, > >On my HDSP 9652 system executing the command > > > > amixer controls > > > > yields a list that appears to be 166 items long, starting with numid=1 > > and ending with numid=166. However, closer study shows numid=2 seems to > > be missing. > > > > Is this an issue with amixer or my card? What function might normally be > > associated with numid=2? > > don't worry, no bug: > > it's not a mixer control but a control for a PCM stream. > that's why amixer doesn't show this element. > > > ciao, > > Takashi --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] buffer_size and period_size
Paul, So with -p 64 -n 2 settings, what number of bytes of audio data is transferred across the PCI bus between each interrupt? I guess I had mistakenly thought -p was setting the number of bytes. I no longer think that is true. Also, does the number of bytes transferred change based on how many channels are enabled? Or does my RME always transfer 26 channels of data even if I am not using some channels? I am assuming that a card like the RME is a bus master, moves so many bytes, and then interrupts to tell the system that the bytes are there. Is this basically the case? Thanks, Mark > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis > Sent: Monday, January 27, 2003 9:32 AM > To: Jozef Kosoru > Cc: [EMAIL PROTECTED] > Subject: Re: [Alsa-devel] buffer_size and period_size > > > >I would like to fully understand the exact meaning of buffer_size and > >period_size and how can I compute the final latency in the full duplex > >processing from these variables. > > period_size = frames between interrupts from the hardware > buffer size = total frames for the hardware buffer > > max output latency = buffer_size > min output latency = buffer_size - period_size > > max input latency = period_size + interrupt overhead > min input latency = 1 frame + interrupt overhead > > the latency numbers assume: > > a) the buffer is generally full > b) you process data 1 period at a time > c) your s/w keeps up with the h/w > d) its an average, computed across a period's worth of data > > --p > > > --- > This SF.NET email is sponsored by: > SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! > http://www.vasoftware.com > ___ > Alsa-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/alsa-devel > > --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] buffer_size and period_size
> -Original Message- > From: Paul Davis [mailto:[EMAIL PROTECTED]] > Sent: Monday, January 27, 2003 10:39 AM > To: Mark Knecht > Cc: [EMAIL PROTECTED] > Subject: Re: [Alsa-devel] buffer_size and period_size > > > >Paul, > > So with -p 64 -n 2 settings, what number of bytes of audio data is > >transferred across the PCI bus between each interrupt? > > the period size is always (as with almost all ALSA metrics) in units > of audio frames (1 sample for each channel). so with JACK running at > -p 64, 64 frames of data are transferred. how many bytes that is > depends on the sample width and the number of channels. Cool, so this says my RME HSDP puts out 26 samples 64 times, and then signals with an interrupt, while my Hammerfall Light puts out 18 samples 64 times? If true, then both cards interrupt at the same rate, but the HDSP 9652 uses more PCI bandwidth. (26/18) Presumably each sample uses 24-bits of audio data, packed in a 32-bit hardware DWORD moving across the PCI bus? This would be clean and easy for software to deal with. If true, then the number of bytes would be 4 bytes/channel * 26 channels * 64 frames = 6656 bytes across the PCI bus between interrupts. (Or desire to interrupt, not necessarily interrupt services.) > > > Also, does the number of bytes transferred change based on how many > >channels are enabled? Or does my RME always transfer 26 channels of data > >even if I am not using some channels? > > its hardware dependent. for the RME, the same amount is always moved, > regardless of how many channels are enabled. in the case of the RME > Hammerfall series, its more accurate to say that you cannot change the > number of channels enabled. this is not true of all other hardware. Sure. Sensible. They just always send 26 channels of data. The loading on the PCI bus is therefore independent of how many channels I'm actually using. > > > I am assuming that a card like the RME is a bus master, moves so many > >bytes, and then interrupts to tell the system that the bytes are > there. Is > >this basically the case? > > yes. keep in mind that this only covers 1 direction: the interrupt > also tells the system that its possible to put data into the "hardware > buffer". Good point. Thanks! --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Automounting my 1394 drives causes Alsa to not load...
Hi, Bit of a problem. This is Redhat 7.3, PlanetCCRMA flow, and the machine has 256MB. Alsa has been working reasonably well for me, but I have two problems that I would really like to fix: 1) Old problem - if my MidiSport 2x2 is plugged in when I cold boot, then Alsa gets loaded when the MidiSport is found. When I get to the part of the boot process where Alsa is supposed to get started, I get a 'Failed' message, telling me Alsa is already running. Even this is OK, but then later when Linux attempt to load the HDSP 9652 drivers, they fail one out of two times saying they cannot allocate memory. 2) When I try to auto-mount my 1394 hard drives by creating an auto-mount entry in /etc/fstab, they may not be turned on, which is legal. However, in this situation Alsa always fails to load. I have to make the drive 'noauto' to get Alsa to start correctly. Both of these problems seem to be solved by warm booting the system. However, that takes time and I certainly shouldn't have to do that. What can I do to solve these problems so that Alsa will come up correctly on my first cold boot. Cheers, Mark --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Automounting my 1394 drives causes Alsa to notload...
On Sat, 2003-02-01 at 12:31, Fernando Pablo Lopez-Lezcano wrote: > > 1) Old problem - if my MidiSport 2x2 is plugged in when I cold boot, > > then Alsa gets loaded when the MidiSport is found. When I get to the > > part of the boot process where Alsa is supposed to get started, I get a > > 'Failed' message, telling me Alsa is already running. Even this is OK, > > but then later when Linux attempt to load the HDSP 9652 drivers, they > > fail one out of two times saying they cannot allocate memory. > > I think the solution to this one is to "blacklist" the alsa driver so > that hotplug does not load it while the system is starting up. To do > that just add a line with "snd-usb-audio" to the end of > /etc/hotplug/blacklist > You probably already have "audio" and "usb-midi" there (the oss kernel > modules that deal with usb audio and midi). > Fernando, Thanks! Early indications are that this helps. I'll keep an eye on it and see how it goes. Cheers, Mark --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Where to report?
Hi, Is Alsa-Dev the right place to report problems with Linux MIDI? (Such as stuck note problems with soft synths.) Thanks, Mark --- This SF.NET email is sponsored by: SourceForge Enterprise Edition + IBM + LinuxWorld = Something 2 See! http://www.vasoftware.com ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: Further info: [Alsa-devel] Bug: ALSA Sequencer or MTPAV - easy to reproduce
Jaroslav,
Hi. Actually, I had been looking around for where to report this sort of
problem. I'm using an HDSP 9652 for MIDI input and getting stuck notes on
all soft synths I'm using. (amSynth, ZynAddSubFx and iiwusynth) I'm at a bit
of a loss as to how to debug this, but I do see the problem.
I have found that it is independent of MIDI applications, as I see the
problem if I just use kaconnect to hook MIDI input to the soft synth and
qjackconnect to hook analog output to my speakers.
Mark
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED]]On Behalf Of Jaroslav
Kysela
Sent: Wednesday, February 12, 2003 12:42 PM
To: Ryan Pavlik
Cc: [EMAIL PROTECTED]
Subject: Re: Further info: [Alsa-devel] Bug: ALSA Sequencer or MTPAV -
easy to reproduce
On Wed, 12 Feb 2003, Ryan Pavlik wrote:
> On Wed, 12 Feb 2003 11:28:35 -0800
> Ryan Pavlik <[EMAIL PROTECTED]> wrote:
>
>
>
> Further info: The bug is definitely above the hardware level. I added
> a printk to snd_mtpav_send_byte() for logging device/bytes sent, and
> came up with the attached log, which I commented on. This log was
> generated by playing the two tracks as described in my previous message.
>
> As you can see (a page or two down, look for '??'), the status byte
> for some midi messages is getting lost before it gets to
> snd_mtpav_send_byte(). I'm going to go through and see if this is due
> to complications elsewhere in mtpav.c, but I'm only about 50% sure
> that's where the problem is.
It seems that mtpav don't remeber the old status byte for each channels.
If it's true, then we need to take care about the expansion in the mtpav
driver, because the sequencer MIDI driver removes duplicated status bytes
to opmitize throughput.
To test this behaviour, please, try this patch:
Index: seq_midi_event.c
===
RCS file: /cvsroot/alsa/alsa-kernel/core/seq/seq_midi_event.c,v
retrieving revision 1.10
diff -u -r1.10 seq_midi_event.c
--- seq_midi_event.c31 Jan 2003 15:19:34 - 1.10
+++ seq_midi_event.c12 Feb 2003 20:41:30 -
@@ -349,6 +349,8 @@
{
unsigned int cmd, type;
+ dev->nostat = 1;
+
if (ev->type == SNDRV_SEQ_EVENT_NONE)
return -ENOENT;
Jaroslav
-
Jaroslav Kysela <[EMAIL PROTECTED]>
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
---
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
---
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: Further info: [Alsa-devel] Bug: ALSA Sequencer or MTPAV - easy to reproduce
Will do. I'll send it along this evening. Thanks, Mark -Original Message- From: Jaroslav Kysela [mailto:[EMAIL PROTECTED]] Sent: Wednesday, February 12, 2003 1:26 PM To: Mark Knecht Cc: [EMAIL PROTECTED] Subject: RE: Further info: [Alsa-devel] Bug: ALSA Sequencer or MTPAV - easy to reproduce On Wed, 12 Feb 2003, Mark Knecht wrote: > Jaroslav, >Hi. Actually, I had been looking around for where to report this sort of > problem. I'm using an HDSP 9652 for MIDI input and getting stuck notes on > all soft synths I'm using. (amSynth, ZynAddSubFx and iiwusynth) I'm at a bit > of a loss as to how to debug this, but I do see the problem. > >I have found that it is independent of MIDI applications, as I see the > problem if I just use kaconnect to hook MIDI input to the soft synth and > qjackconnect to hook analog output to my speakers. Could you try the command 'dd if=/dev/snd/midiC0D0 of=abcd bs=1' and play some notes on connected keyboard? In the file abcd will be the raw context of midi input, so we can determine, if it's driver or sequencer problem. Jaroslav - Jaroslav Kysela <[EMAIL PROTECTED]> Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- 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: Further info: [Alsa-devel] Bug: ALSA Sequencer or MTPAV - easyto reproduce
On Wed, 2003-02-12 at 13:25, Jaroslav Kysela wrote: > On Wed, 12 Feb 2003, Mark Knecht wrote: > > > Jaroslav, > >Hi. Actually, I had been looking around for where to report this sort of > > problem. I'm using an HDSP 9652 for MIDI input and getting stuck notes on > > all soft synths I'm using. (amSynth, ZynAddSubFx and iiwusynth) I'm at a bit > > of a loss as to how to debug this, but I do see the problem. > > > >I have found that it is independent of MIDI applications, as I see the > > problem if I just use kaconnect to hook MIDI input to the soft synth and > > qjackconnect to hook analog output to my speakers. > > Could you try the command 'dd if=/dev/snd/midiC0D0 of=abcd bs=1' and play > some notes on connected keyboard? In the file abcd will be the raw context > of midi input, so we can determine, if it's driver or sequencer problem. > > Jaroslav Hi, OK, as requested, here's a few chords and some notes. However, I cannot hear the soft synth when doing this, and I normally only get a stuck note once every 5-10 minutes, so there's no guarantee that there's anything interesting in here. Maybe I could record something, using Rosegarden, until I get a stuck note, and give you a MIDI file? Don't know if that would be of much help as this problem is not terribly repeatable yet. Is there any way I can pipe this input to my soft synth so I can hear what I'm doing? Cheers, Mark midi_notes Description: Binary data
RE: [Alsa-devel] playing underruns
Also check out the Planet for more info on this. Fernando has some suggestions for Redhat there. Cheers, Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis Sent: Thursday, February 13, 2003 11:11 AM To: Chris Raphael Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] playing underruns >/sbin/hdparm /dev/hda2 > >I get: > >/dev/hda2: > multcount = 16 (on) > I/O support = 0 (default 16-bit) > unmaskirq = 0 (off) > using_dma = 1 (on) > keepsettings = 0 (off) > nowerr= 0 (off) > readonly = 0 (off) > readahead = 8 (on) > geometry = 4864/255/73, sectors = 36869175, start = 4225095 > >with similar results for the other hda's. I don't know if this >is the question you were asking, though, since this doesn't seem >to have much info. yep, this doesn't look too good, though its not a complete disaster. please read this: http://linux.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html keep in mind that some distributions (RH included, i think) have fixed this issue somewhat, though they may not have gone far enough for low latency audio. >I don't have the low latency patch. you will probably need it. the standard kernel in RH7 is not up to the task. --p --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] IEEE 1394
Pavel, You're in the wrong forum. Go to www.linux1394.org and pick up the information you need to get started there. If you want to develop 1394 applications there are some mailing lists there with other like minded people. Good luck, Mark -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of PavelSent: Thursday, February 13, 2003 4:34 AMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: [Alsa-devel] IEEE 1394 Hi, I would like to ask about situation in Linux about one problem. Does Linux kernel or Alsa drivers supports IEEE 1394 standart? If yes, could you recomend me some references and advices to be able to use it and program it to create applications with IEEE 1394? If no, could you recomend me some advices or some documentation to be able to create IEEE 1394 driver? Thanks Ing. Pavel Nikitenko
[Alsa-devel] Please explain Alsa Interface MIDI numbering PLEASE!
Hi, I'm having a great deal of confusion about how Alsa is handling my MIDI hardware. This is spilling over into unintended consequences in Rosegarden that I think none of us understand. Couple someone with some background in this please explain? Thanks. I have two 2-port MIDI devices on this system. One is an RME HDSP 9652 with two MIDI ports, and the other is a hot pluggable MidiSport 2x2. I attach two screen shots of kaconnect, one with and one without the 2x2 plugged in. My questions: 1) In the screen shot "without_2x2.png" I see two read ports and two write ports. Please explain why they are called 64:0 External MIDI 0 64:32 External MIDI 0 Why is my HDSP given the apparent name '64'? Why the :0 and :32? I would have thought :0 and :16 would make more sense from a channel numbering point of view, or :0 and :1 from an interface point of view. What's going on? 2) In the screen shot "with_2x2.png" I've plugged in the MidiSport 2x2. New devices show up in kaconnect. However, instead of showing 2 read ports and 2 write ports, I am getting 4 read ports and no write ports. Please explain why the MidiSport is given the names 72:0 External MIDI 1 72:1 External MIDI 1 72:2 External MIDI 1 72:3 External MIDI 1 Shouldn't this be just :0 and :1 for both the read and write ports? I get the feeling that BOTH of the drivers for these devices are hosed. What's up with these things? I do not understand why Alsa gives these devices numbers in the first place, nor how the numbers are assigned. How can I change the names that are displayed so that "64:0 External MIDI 0" shows the name "HDSP 9652 Port 1" "64:32 External MIDI 0" shows the name "HDSP 9652 Port 2" "72:0 External MIDI 1" shows the name "MidiSport 2x2 Port A" "72:1 External MIDI 1" shows the name "MidiSport 2x2 Port B" Thanks very, very much in advance, Mark <><>
Re: [Alsa-devel] Please explain Alsa Interface MIDI numberingPLEASE!
Pedro, I run on the PlanetCCRMA flow. My current Alsa appears to be from 1/21/03, or about a month ago. Was rc7 after that? Thanks, Mark On Sun, 2003-02-16 at 11:43, Pedro Lopez-Cabanillas wrote: > On Sunday 16 February 2003 19:53, Mark Knecht wrote: > > 2) In the screen shot "with_2x2.png" I've plugged in the MidiSport 2x2. > > New devices show up in kaconnect. However, instead of showing 2 read > > ports and 2 write ports, I am getting 4 read ports and no write ports. > > Please explain why the MidiSport is given the names > > > > 72:0 External MIDI 1 > > 72:1 External MIDI 1 > > 72:2 External MIDI 1 > > 72:3 External MIDI 1 > > > > Shouldn't this be just :0 and :1 for both the read and write ports? > > Yes. This was a bug in snd-usb-audio for 0.9.0rc7, fixed now in ALSA CVS, see: > http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg06225.html > > Regards, > Pedro > > -- > ALSA Library Bindings for Pascal > http://alsapas.alturl.com > --- 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: [Alsa-devel] Please explain Alsa Interface MIDI numberingPLEASE!
Sorry... I see the date on the email about the patch was a few days later in February, so I definitely do not have the patch. Thanks On Sun, 2003-02-16 at 11:46, Mark Knecht wrote: > Pedro, >I run on the PlanetCCRMA flow. My current Alsa appears to be from > 1/21/03, or about a month ago. Was rc7 after that? > > Thanks, > Mark > > On Sun, 2003-02-16 at 11:43, Pedro Lopez-Cabanillas wrote: > > On Sunday 16 February 2003 19:53, Mark Knecht wrote: > > > 2) In the screen shot "with_2x2.png" I've plugged in the MidiSport 2x2. > > > New devices show up in kaconnect. However, instead of showing 2 read > > > ports and 2 write ports, I am getting 4 read ports and no write ports. > > > Please explain why the MidiSport is given the names > > > > > > 72:0 External MIDI 1 > > > 72:1 External MIDI 1 > > > 72:2 External MIDI 1 > > > 72:3 External MIDI 1 > > > > > > Shouldn't this be just :0 and :1 for both the read and write ports? > > > > Yes. This was a bug in snd-usb-audio for 0.9.0rc7, fixed now in ALSA CVS, see: > > http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg06225.html > > > > Regards, > > Pedro > > > > -- > > ALSA Library Bindings for Pascal > > http://alsapas.alturl.com > > > > > > > --- > 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 --- 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: [Alsa-devel] Please explain Alsa Interface MIDI numbering PLEASE!
Pedro, Is there any online information about how to use Midiman's firmware? Thanks, Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Pedro Lopez-Cabanillas Sent: Sunday, February 16, 2003 12:34 PM To: Mark Knecht Cc: Alsa-Devel; Rosegarden-Devel; Fernando Pablo Lopez-Lezcano Subject: Re: [Alsa-devel] Please explain Alsa Interface MIDI numbering PLEASE! On Sunday 16 February 2003 20:46, Mark Knecht wrote: > Pedro, >I run on the PlanetCCRMA flow. My current Alsa appears to be from > 1/21/03, or about a month ago. Was rc7 after that? > Yes, 0.9.0rc7 is dated 2003-01-28 PlanetCCRMA's ALSA drivers came from a CVS snapshot taken at 2003-01-21 The bug was introduced at 2003-01-10 So, you should use current CVS driver, or wait for a PlanetCCRMA update, or use Midiman's firmware. For other USB MIDI fully compliant devices, like Evolution's keyboards, a fixed driver is needed. Regards, Pedro > On Sun, 2003-02-16 at 11:43, Pedro Lopez-Cabanillas wrote: > > On Sunday 16 February 2003 19:53, Mark Knecht wrote: > > > 2) In the screen shot "with_2x2.png" I've plugged in the MidiSport 2x2. > > > New devices show up in kaconnect. However, instead of showing 2 read > > > ports and 2 write ports, I am getting 4 read ports and no write ports. > > > Please explain why the MidiSport is given the names > > > > > > 72:0 External MIDI 1 > > > 72:1 External MIDI 1 > > > 72:2 External MIDI 1 > > > 72:3 External MIDI 1 > > > > > > Shouldn't this be just :0 and :1 for both the read and write ports? > > > > Yes. This was a bug in snd-usb-audio for 0.9.0rc7, fixed now in ALSA CVS, > > see: > > http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg06225.htm > >l > > > > Regards, > > Pedro -- ALSA Library Bindings for Pascal http://alsapas.alturl.com --- 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 --- 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: [Rosegarden-devel] Re: [Alsa-devel] Please explain Alsa Interface MIDI numbering PLEASE!
Pedro, Thanks! I'll try that out this evening. I wonder if anyone will respond on the weird HDSP numbering, and where I make a configuration change to get Alsa to use real names? I hope so. Cheers, Mark > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]]On Behalf Of Pedro > Lopez-Cabanillas > Sent: Sunday, February 16, 2003 3:31 PM > To: Mark Knecht > Cc: Alsa-Devel; Rosegarden-Devel > Subject: [Rosegarden-devel] Re: [Alsa-devel] Please explain Alsa > Interface MIDI numbering PLEASE! > > > On Monday 17 February 2003 00:03, Mark Knecht wrote: > > Pedro, > >Is there any online information about how to use Midiman's firmware? > > Thanks, > > Mark > > Yes. Clemens wrote an easy to use utility to extract and install > Midiman's > firmware, see: > http://www.informatik.uni-halle.de/~ladischc/midisport_linux_firmware.html > > Regards, > Pedro > > -- > ALSA Library Bindings for Pascal > http://alsapas.alturl.com > > > > --- > This sf.net email is sponsored by:ThinkGeek > Welcome to geek heaven. > http://thinkgeek.com/sf > ___ > Rosegarden-devel mailing list > [EMAIL PROTECTED] > https://lists.sourceforge.net/lists/listinfo/rosegarden-devel > > --- 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: [linux-audio-user] Re: [Alsa-devel] Please explain AlsaInterface MIDI numbering PLEASE!
Clemens, Thanks. This is helpful, although questions remain. FYI - my machine doesn't have pmidi, so I cannot run that now. [mark@Godzilla mark]$ aconnect -io client 0: 'System' [type=kernel] 0 'Timer ' 1 'Announce' client 64: 'External MIDI 0' [type=kernel] 0 'MIDI 0-0' 32 'MIDI 0-1' client 72: 'External MIDI 1' [type=kernel] 0 'Midisport 2x2 Port 0' 1 'Midisport 2x2 Port 1' 2 'Midisport 2x2 Port 2' 3 'Midisport 2x2 Port 3' [mark@Godzilla mark]$ The above information is certainly a bit more readable, but it seems to still be, at the least, inconsistent. 1) For client 64, which is an HDSP 9652, there are two rawmidi ports. However, the info above says they are labeled '0' and '32'. Should they not be 0 & 1? If this is an error, then what needs to be fixed? The HDSP 9652 driver? 2) Why does the HDSP 9652 not tell me its name like the MidiSport does? The MidiSport info above is with the Win2K firmware installed as per your extraction program. It actually didn't change from the way Fernando had me install it, so I suppose that his installation had the real Midiman firmware and not the open source firmware. Apparently I'll continue to get the wrong number of ports on that device until I can get Alsa itself upgraded. Thanks, Mark On Mon, 2003-02-17 at 01:21, Clemens Ladisch wrote: > Mark Knecht wrote: > > 1) In the screen shot "without_2x2.png" I see two read ports and two > > write ports. Please explain why they are called > > > > 64:0 External MIDI 0 > > 64:32 External MIDI 0 > > > > Why is my HDSP given the apparent name '64'? > > This isn't the name, it's the sequencer client number. In theory, it > should not be necessary to identify devices by this. > > 0-63 are reserved for the ALSA core. 64-127 are used by sound cards, with > each card getting 8 (64-71, 72-79, etc.). 128-255 are for use by > applications. > > > Why the :0 and :32? I would have thought :0 and :16 would make more > > sense from a channel numbering point of view, or :0 and :1 from an > > interface point of view. What's going on? > > These ports are not native sequencer ports implemented directly by the > driver but are emulated on top the rawmidi ports. There can be 256 ports > per sequencer client, and 8 rawmidi devices per card, so each rawmidi > device (which can have an unspecified number of subdevices=ports) is > mapped to a group of 32 (256/8) sequencer ports. > > If the two rawmidi ports would have been subdevices of one device, they > would have been mapped to port numbers :0 and :1. > > >How can I change the names that are displayed so that > > "64:0 External MIDI 0" shows the name "HDSP 9652 Port 1" > > "64:32 External MIDI 0" shows the name "HDSP 9652 Port 2" > > "72:0 External MIDI 1" shows the name "MidiSport 2x2 Port A" > > "72:1 External MIDI 1" shows the name "MidiSport 2x2 Port B" > > "External MIDI x" is the client name, which is the same for all ports of > the same client. It seems that kaconnect doesn't show the port name, which > would be what you want. Please complain to the author of kaconnect. :-) > > To show the port names, run "aconnect -io" or "pmidi -l". > > > HTH > Clemens > > --- 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: [linux-audio-user] Re: [Alsa-devel] Please explain Alsa Interface MIDI numbering PLEASE!
> >0 'Timer ' > >1 'Announce' > >client 64: 'External MIDI 0' [type=kernel] > >0 'MIDI 0-0' > > 32 'MIDI 0-1' > >client 72: 'External MIDI 1' [type=kernel] > >0 'Midisport 2x2 Port 0' > >1 'Midisport 2x2 Port 1' > >2 'Midisport 2x2 Port 2' > >3 'Midisport 2x2 Port 3' > >[mark@Godzilla mark]$ > > > > > > The above information is certainly a bit more readable, but it seems > >to still be, at the least, inconsistent. > > > >1) For client 64, which is an HDSP 9652, there are two rawmidi ports. > >However, the info above says they are labeled '0' and '32'. Should they > >not be 0 & 1? If this is an error, then what needs to be fixed? The HDSP > >9652 driver? > > no, the port numbers are 0 and 32, but in the name, its 0 and 1. Well, OK, I guess I don't understand the meaning of 'ports' then. The HDSP only has two sets of in and out connectors. Are these not ports? Or does the Alsa spec think that each 'port' is somehow combination of a MIDI connector and a channel or something? How is it that a single input uses up 32 port number? (HDSP 9652 MIDI 1 seems to go from port 0 to port 31, and I guess #2 goes from 32-63.) > > >2) Why does the HDSP 9652 not tell me its name like the MidiSport does? > > its using a copy of some generic ALSA code that just calls the ports > "MIDI C P" where C=card number and P=physical port number. i'll change > this when i add the fixes for the mixer and the h/w names. > This would be very helpful. Thanks! --- 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
[Alsa-devel] kaconnect question and enhancement request
Hi, I'm sorry, but I'm not at all sure who developed kaconnect. I like this little app quite a bit, however, it won't allow one thing I'd certainly like - to be able to hook a MIDI input to its corresponding MIDI output. Why doesn't this work? I can hook MidiSport 2x2 In A to Out B, but not to Out A, which I would really like to be able to do sometimes. Is there a technical reason that this cannot be done? As an enhancement request, I sure would like kaconnect to have the ability to filter certain MIDI events, like controllers, or key pressure, etc. I understand that I might be difficult to do this on a path by path basis, although it would be useful at times. Saving a set of connections would be cool also. Anyway, thanks for this little app that I use every day. Cheers, Mark --- 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: [Alsa-devel] kaconnect question and enhancement request
> -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED] Behalf Of Takashi Iwai > Sent: Tuesday, February 25, 2003 2:10 AM > To: Mark Knecht > Cc: Alsa-Devel > Subject: Re: [Alsa-devel] kaconnect question and enhancement request > > no idea.. doesn't aconnect in alsa-utils work? > Takashi-san, Thanks. I tried aconnect, and read through the --help stuff, but couldn't figure out the command to hook together two ports. Could you give an example? Everything I tried resulted in error messages. I also wondered about hooking a single input to multiple outputs, so if you could show an example of that, I would appreciate it. Thanks, Mark --- 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: [Alsa-devel] kaconnect question and enhancement request
On Tue, 2003-02-25 at 07:52, Takashi Iwai wrote: > for connecting between the same input and output, just run like > > % aconnect 64:0 64:0 > > > Takashi-san, Thanks. This works fine. If 64:0 is connected to 64:0 in aconnect, then kaconnect shows it and will allow it to be disconnected. However kaconnect will not make the connection itself, so I suppose this is an oversight in kaconnect. Thanks for your help. Cheers, Mark --- This SF.net email is sponsored by: Scholarships for Techies! Can't afford IT training? All 2003 ictp students receive scholarships. Get hands-on training in Microsoft, Cisco, Sun, Linux/UNIX, and more. www.ictp.com/training/sourceforge.asp ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
