[Alsa-devel] API questions
I have posted my code in question here:
http://rafb.net/paste/results/nI811998.html
I have been studying the ALSA driver and lib API, and in doing so have
written a simple raw pcm player. I used the tutorials written by Dr
Matthias Nagorni and Paul Davis as templates, along with alot of gdb
sessions with aplay. It is by no means intended for any real use, its
purpose is to be used as a soft 'breadboard' so to speak; a simple tool
for dropping functions in, examining hardware, etc. When I feel I'm
ready, the next step is to make a callback based version, as per the
Davis howto. Ultimately, I wish to forget all of this (jack). I'm
spending alot of time at the alsa level because I'm interested highly in
the device driver api as well as applications.
I was able to get it working very easily on my laptop (ymfpci based) and
was feeling pretty sexy at this point. I started adding stuff like a
getopt routine (originally i was changing the struct pm values and
recompiling over and over), all kinds of info, hw_params_get and test
functions, various debugging functions, throwing all kinds of hw_params
at it (periods, period size/time buffer size/time, etc), to closely
examine the inner workings of the driver, hardware, etc. I was already
starting to look into the jack API (which sent me directly to pthreads
as a prerequisite). I'm also refreshing my areas of C that were rusty
too, whence all the struct and pointer to struct usage (those were weak
areas for me). Then I moved to my desktops to find it fail on a few
devices: the ice1712 (delta 1010LT and EZ8) and the intel8x0. It works
on the ymfpci and the via82xx. I noticed a problem with the output of
snd_pcm_hw_params_dump showing RATE: NONE on my program.
aplay's call:
snd_pcm_hw_params_set_rate_near(handle, params, hwparams.rate, 0);
my pcmplay's call:
snd_pcm_hw_params_set_rate_near(pcm_handle, hwparams,
(params-rate), dir);
Changing arg4 in my program to 0 fixed the problem. Looks like the
recent change to this function bit me again. I sent a post a while back
about the return value and arg3, looks like arg4(int *dir) has changed
as well. Confirmation? Kinda weird that it works on some and not other
devices though, that really thru me for a while. Here is the link once
again to the inaccurate documentation:
http://www.alsa-project.org/alsa-doc/alsa-lib/group___p_c_m___h_w___params.html#a58
This email was actually started to ask for help in finding that problem,
which I found while writing it. So now on to the questions that I had
been developing before I got sidetracked by that bug, if I can remember
them all:)
If I understand correctly, a hardware buffer is a chuck of ram in the
audio device itself of a fixed size. I think that the author of a
device driver defines the max buffer size by referring to the hardware
specs of the chip. Is there more to it than this? I ask because first,
I can't seem to get a buffersize setting out of a ymfpci 744 of 256K no
matter what hw_params I throw at it, anything higher that 64K (65536
bytes) causes a set buffersize error. I doublechecked to make sure I
wasn't confusing bytes with frames, and I'm not. . I got that value of
256K from the driver code, show below. I'm also curious about the
comment. Again, isn't this a hardware aspect, and not a question of
enough or not? Was it perhaps, that the author was guessing due to lack
of specs at the time or something?
static snd_pcm_hardware_t snd_ymfpci_playback =
{
.info = (SNDRV_PCM_INFO_MMAP |
SNDRV_PCM_INFO_MMAP_VALID |
SNDRV_PCM_INFO_INTERLEAVED |
SNDRV_PCM_INFO_BLOCK_TRANSFER |
SNDRV_PCM_INFO_PAUSE |
SNDRV_PCM_INFO_RESUME),
.formats = SNDRV_PCM_FMTBIT_U8 | SNDRV_PCM_FMTBIT_S16_LE,
.rates =SNDRV_PCM_RATE_CONTINUOUS | SNDRV_PCM_RATE_8000_48000,
.rate_min = 8000,
.rate_max = 48000,
.channels_min = 1,
.channels_max = 2,
.buffer_bytes_max = 256 * 1024, /* FIXME: enough? */
.period_bytes_min = 64,
.period_bytes_max = 256 * 1024, /* FIXME: enough? */
.periods_min = 3,
.periods_max = 1024,
.fifo_size =0,
};
I had lots more, but I think they were all based on confusion about that
bug. Guess it's back to the drawing board for now...
--
http://nostar.isa-geek.com/
---
This SF.Net email is sponsored by: IBM Linux Tutorials
Free Linux tutorial presented by Daniel Robbins, President and CEO of
GenToo technologies. Learn everything from fundamentals to system
administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click
Re: [Alsa-devel] Opening dev/dsp takes very long
I really want to resolve this bug, but there has been little help so far. I haven't got any response from Perex, too. He was asigned to this bug via alsa bug report... Please, someone needs to tell me wich modules are connected with the functions that took so long, so I can check revision of tthe modules to find the cause of the delay. Additionally, could someone tell me how to get debug-output from alsa (Kernel 2.6) ? Regards, Lars. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Fw: [Bug 76413] arts does not follow ALSA API
might be of interest to you guys... Begin forwarded message: Date: 19 Mar 2004 13:50:08 - From: Allan Sandfeld [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug 76413] arts does not follow ALSA API --- You are receiving this mail because: --- You are a voter for the bug, or are watching someone who is. http://bugs.kde.org/show_bug.cgi?id=76413 kde carewolf com changed: What|Removed |Added --- - Status|NEW |UNCONFIRMED --- Additional Comments From kde carewolf com 2004-03-19 14:50 --- Okay, having researched the problem. The reason that dmix doesnt work with aRts has nothing to do with how we use the alsa API because all our assumptions are still true. snd_pcm_poll_descriptors() returns exactly one descriptor, but calling select upon this descriptor no matter how it is done will _never_ return. In other words the reason it doesnt work is that dmix is broken! I've looked a bit at how other projects use ALSA, and it seems we could make it work if we used another API and disregarded the broken descriptors alltogether, in other words if we rewrite the entire audio-subsystem of aRts to work-around a bug in ALSA (I have no intention of doing so). Btw. I did make playback over dmix work, but the it required using timing events rather than IO-events and thus CPU-usage was unacceptable. -- kT --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Fw: [Bug 76413] arts does not follow ALSA API
He sounds pissed.. :) If you get pissed by these forwards, please tell me.. I figured they might be of interest.. Begin forwarded message: Date: 19 Mar 2004 15:05:31 - From: Allan Sandfeld [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug 76413] arts does not follow ALSA API --- You are receiving this mail because: --- You are a voter for the bug, or are watching someone who is. http://bugs.kde.org/show_bug.cgi?id=76413 --- Additional Comments From kde carewolf com 2004-03-19 16:05 --- CVS commit by carewolf: After venting my fury I calmed down and looked at the dmix-code. It seems it is really more borken than broken, and nothing we can't work around. - Make aRts work with dmix. Two important changes: 1. Dmix uses read-events to signify write-events, so we need to autodetect what kind of crack ALSA is smoking today. 2. Dmix needs to be started like a recorder even if this is contrary to the ALSA API documentation. If everything works like expected I will backport and close bugs 76413 and 70802. CCMAIL: 76413 bugs kde org CCMAIL: 70802 bugs kde org M +110 -48 audioioalsa9.cc 1.6 -- kT --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Fw: [Bug 76413] arts does not follow ALSA API
Florian Schmidt wrote: He sounds pissed.. :) If you get pissed by these forwards, please tell me.. I figured they might be of interest.. Begin forwarded message: Date: 19 Mar 2004 15:05:31 - From: Allan Sandfeld [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [Bug 76413] arts does not follow ALSA API --- You are receiving this mail because: --- You are a voter for the bug, or are watching someone who is. http://bugs.kde.org/show_bug.cgi?id=76413 --- Additional Comments From kde carewolf com 2004-03-19 16:05 --- CVS commit by carewolf: After venting my fury I calmed down and looked at the dmix-code. It seems it is really more borken than broken, and nothing we can't work around. - Make aRts work with dmix. Two important changes: 1. Dmix uses read-events to signify write-events, so we need to autodetect what kind of crack ALSA is smoking today. 2. Dmix needs to be started like a recorder even if this is contrary to the ALSA API documentation. If everything works like expected I will backport and close bugs 76413 and 70802. CCMAIL: 76413 bugs kde org CCMAIL: 70802 bugs kde org M +110 -48 audioioalsa9.cc 1.6 If there is a bug in alsa, we will fix it. Can you post a small program to demonstrate the problem. Cheers James --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Fw: [Bug 76413] arts does not follow ALSA API
On Fri, 19 Mar 2004, James Courtier-Dutton wrote: --- You are receiving this mail because: --- You are a voter for the bug, or are watching someone who is. http://bugs.kde.org/show_bug.cgi?id=76413 CCMAIL: 76413 bugs kde org CCMAIL: 70802 bugs kde org M +110 -48 audioioalsa9.cc 1.6 If there is a bug in alsa, we will fix it. Can you post a small program to demonstrate the problem. It's not a bug, but this guy definitely wants to simplify his work. He uses file descriptors directly without snd_pcm_poll_descriptors_revents(). The dmix plugin (and dshare) are first plugins which don't return POLLOUT for playback but POLLIN (because timer events are used as the event source). Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] [PATCH] usb-usx2y text updates
Hi, here are some unimportant README and Kconfig updates for the usb-usx2y driver. bye, martin -- Living on earth may be expensive, but it includes an annual free trip around the sun. --- alsa-driver/usb/usx2y/Kconfig.ORIGINAL Fri Mar 19 22:11:10 2004 +++ alsa-driver/usb/usx2y/Kconfig Fri Mar 19 22:13:39 2004 @@ -1,6 +1,7 @@ config SND_USB_USX2Y - tristate Tascam USB US-122 and US-428 driver + tristate Tascam USB US-122, US-224 and US-428 driver depends on SND USB help - Say 'Y' or 'M' to include support for Tascam USB US-122 and US-428. + Say 'Y' or 'M' to include support for Tascam USB US-122, US-224 + and US-428. --- alsa-tools/usx2yloader/README.ORIGINAL Fri Mar 19 22:00:23 2004 +++ alsa-tools/usx2yloader/README Fri Mar 19 22:09:40 2004 @@ -7,36 +7,37 @@ Usx2yloader is a helper program to load the 2nd Phase firmware binaries onto the Tascam USX2Y USB soundcards. -It has proven to work so far only for the US428. -US122 US224 will hopefully follow. -The snd-usb-us428 module requires this program. +It has proven to work so far for the US122, US224 and US428. +The snd-usb-usx2y module requires this program. -US428 initialisation outlined +USX2Y initialisation outlined = A. Phase 1 -A.1. US428 is plugged to the PC and powered on. +A.1. USx2y is plugged to the PC and powered on. This makes the kernel see a new USB-device with the Vendor/Product - ID 0x1604/0x8000. + ID 0x1604/0x8000 (US428), 0x1604/0x8004 (US224) or 0x1604/0x8006 + (US122). The kernel reacts by starting the usb-hotplug script. A.2. The usb-hotplug script starts the executable fxload, - which transfers the EZUSB firmware to the US428. -A.3. The US428 disconnects itself from the USB-Bus and ... (see Phase 2). + which transfers the EZUSB firmware to the USx2y. +A.3. The USx2y disconnects itself from the USB-Bus and ... (see Phase 2). B. Phase 2 -B.1. The US428 reintroduces itself as USB-device with the Vendor/Product - ID 0x1604/0x8001. - The kernel reacts by loading the module snd-usb-us428, if it is not +B.1. The USx2y reintroduces itself as USB-device with the Vendor/Product + ID 0x1604/0x8001 (US428), 0x1604/0x8005 (US224) or 0x1604/0x8007 + (US122) + The kernel reacts by loading the module snd-usb-usx2y, if it is not already loaded. -B.2 The module snd-usb-us428 takes the US428 as its device and sets up +B.2 The module snd-usb-usx2y takes the USx2y as its device and sets up a hardware dependent interface. (The module doesn't create any pcm nor midi devices now.) B.3 Subsequently the kernel starts the usb-hotplug script, which launches usx2yloader. -B.4 usx2yloader transfers the 2nd Phase firmware binary to the US428 by means +B.4 usx2yloader transfers the 2nd Phase firmware binary to the USx2y by means of the hardware dependent interface. When this transfer finishes, - the snd-usb-us428 module creates the pcm- and midi-devices. + the snd-usb-usx2y module creates the pcm- and midi-devices. Initialisation is complete. @@ -63,7 +64,7 @@ - tascam_fw - tascam_fpga and the Firmwarefiles. -You also need hotplug to be installed. +You also need fxload and hotplug to be installed. FIRMWAREFILES
Re: [Alsa-devel] Opening dev/dsp takes very long
I used the latest alsa-tarballs to upgrade alsa-lib, alsa-driver and alsa-oss. To make it short: The problem is even worse now ! This is the output from strace (relevant part): . . 0.000531 ioctl(4, SNDCTL_DSP_RESET, 0) = 0 0.000232 ioctl(4, SNDCTL_DSP_GETFMTS, 0xb668) = 0 0.510506 ioctl(4, SNDCTL_DSP_SETFMT, 0xb668) = 0 0.506515 ioctl(4, SNDCTL_DSP_STEREO, 0xb668) = 0 0.504940 ioctl(4, SOUND_PCM_READ_RATE, 0xb668) = 0 0.065604 ioctl(4, SNDCTL_DSP_GETBLKSIZE, 0x80a5824) = 0 0.000302 ioctl(4, SNDCTL_DSP_SYNC, 0) = 0 0.000250 munmap(0x40016000, 4096) = 0 . . ..now it's not just a single call that takes too long, but _three_ of them. There has to be someone who nows about the changes made from the alsa used in 2.6.4 and the current release, this way we could probably locate the source for the _additional_ delay introduced, maybe that'll lead us to a solution for the whole issue ? --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Fw: [Bug 76413] arts does not follow ALSA API
On Fri, Mar 19, 2004 at 08:30:13PM +, James Courtier-Dutton wrote: The guys there just don't understand what you told them. If they took the time to actually read what you said, they could easily fix their problem. Summary: - No bug in alsa. Summary 2: There seem to be quite a lot of projects that have problems to get native alsa support right: wine, winex, arts, xmms... How about a alsa application developers meeting once per month on IRC? If that meeting would be announced on the developer mailing list of projects that are known to use alsa, this might actually help. The invitation should contain something along the line: If you have written code to use alsa, you should participate. Either because you did it right and can help others to do so too or because you didn't and in that case you should want to improve. Ciao Jörg -- Joerg Mayer [EMAIL PROTECTED] We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Fw: [Bug 76413] arts does not follow ALSA API
Joerg Mayer wrote: On Fri, Mar 19, 2004 at 08:30:13PM +, James Courtier-Dutton wrote: The guys there just don't understand what you told them. If they took the time to actually read what you said, they could easily fix their problem. Summary: - No bug in alsa. Summary 2: There seem to be quite a lot of projects that have problems to get native alsa support right: wine, winex, arts, xmms... wine is only just starting to support alsa properly, due mainly to lack of real need to alsa support for a long time. They are starting to support it well now. xmms don't support it well for obvious reasons. They charge people for OSS drivers, so the xmms alsa driver has to look worse! How about a alsa application developers meeting once per month on IRC? If that meeting would be announced on the developer mailing list of projects that are known to use alsa, this might actually help. Just reading the docs correctly should help. I hang out on #alsa on freenode quite a lot, and will help if I have the time. The invitation should contain something along the line: If you have written code to use alsa, you should participate. Either because you did it right and can help others to do so too or because you didn't and in that case you should want to improve. Ciao Jörg --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: Fw: [Bug 76413] arts does not follow ALSA API
James Courtier-Dutton [EMAIL PROTECTED] writes: Joerg Mayer wrote: On Fri, Mar 19, 2004 at 08:30:13PM +, James Courtier-Dutton wrote: The guys there just don't understand what you told them. If they took the time to actually read what you said, they could easily fix their problem. Summary: - No bug in alsa. Summary 2: There seem to be quite a lot of projects that have problems to get native alsa support right: wine, winex, arts, xmms... wine is only just starting to support alsa properly, due mainly to lack of real need to alsa support for a long time. They are starting to support it well now. xmms don't support it well for obvious reasons. They charge people for OSS drivers, so the xmms alsa driver has to look worse! The funny thing is that they can't even get that right, unless, of course, you consider random skips a sign of correctness. -- Måns Rullgård [EMAIL PROTECTED] --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Major problem with RME HDSP/Multiface and a 64-bit AMD laptop
First off I would like to extend my sincere apologies for my atrocious cross-posting. I am currently in a rather desperate situation and would highly appreciate any help I can get in this matter. Begin long blurb I recently got my hands on the eMachines M6807 64-bit Athlon 3000+ and I must say that the notebook is very nice. The gripes I do have about it are mostly of cosmetic nature. The performance is in many ways unmatched. After owning the notebook for just about a month I finally found some free time to install the Multiface/HDSP on it. I was immediately very unpleasantly surprised by the fact that the sound output using the ASIO drivers (and Linux ALSA drivers) yielded similar results -- distorted audio. Now here's the catch. When I use the soundcard in mme, DirectX, or any other driver form, the soundcard works perfectly (albeit no multichannel capability). But when I use ALSA in Linux or ASIO in Windoze (XP Home version), the sound plays as if it's interpreted slower than it should be (2 whole steps, or 4 semitones lower and comparably slower) with a bad distortion, as if one is using a very lousy vocoder. There are no drop-outs or choppiness (I did not try JACK, though, so I don't know about the explicit xruns) which leads me to believe that the throughput is not the culprit, but the output simply is useless. Here's some additional info/problems I am aware of: 1) The manufacturer of the notebook is Arima (company that supplies many other companies with the same chipset/chasis) has shipped this notebook with a crappy BIOS (Linux at boot time complains about DSDT being all fubared and fails to properly allocate IRQ's with the acpi turned on; also apic seems to be fubared as well). Some of these issues have been addressed in the 2.6.2 kernels via several patches with a spotty success and currently I need to boot with no acpi or apic to get everything working properly (otherwise almost no peripheral works properly). So, I know for a fact that BIOS is sucking rather bad... Contacting support so far has only suggested that there should be some bios updates coming up soon, but I'll believe it when I see it (OTOH this model is supposedly selling rather well as it has been apparently licensed by at least 6 different companies across the world including the voodoopc, so I guess that should provide some leverage). 2) I am using Mdk 10.0 Community release. No problems there that I can notice. Installed the hdsp utils and everything worked like a charm, except of course for the sound output. 3) The pcmcia card in XP is detected as the generic pcmcia and is using default XP drivers without any conflicts and/or apparent problems. 4) The pcmcia card (at least in Windows) is sharing its IRQ only with the HDSP when plugged in (IRQ 17 -- there are total of 24 due to APIC being enabled in XP), but I don't think that should be considered a conflict (please correct me if I am wrong). 5) In Linux due to fact that the computer boots without APCI and APIC enabled, my guess is that it is using only first 15 IRQ's (like the old APM-based PC), although I need to further investigate this. To the best of my knowledge no IRQ conflicts have been reported by the syslog when using this setup. 6) The pcmcia cardbus is using the yenta_socket driver in Linux, but curiously cannot be used with the APCI (most likely due to fubared BIOS), as that immediately freezes the system. 7) In Windows, I tried 2.53 and 2.62 drivers, with the latest firmware (11). Using different drivers made no difference. I tried several ASIO-capable applications in order to make sure this was the case. 8) No errors during use of Multiface are reported in either Linux nor Windows. Finally, having used Multiface on Inspiron laptops, I am quite familiar with the sound that is being generated by the lousy throughput (crackly stuff) and I must say that while this sounds very similar, there are couple of things that make this sound different: 1) No matter which latency I select in hdsp configuration tool, the sound remains the same. 2) When overclocking the laptop (this beast that runs at 1.8GHz oc's via software without a hitch to 2GHz with no overheating and no instability whatsoever), the pitch and the speed of the output rises (wtf?). At 2GHz it's about 2 semitones higher (and comparably faster). I am having a feeling that if I could oc it for another 200MHz, I would have the right playback speed :-). OTOH, when the laptop downclocks to preserve battery (800MHz) the sound playback remains at approx. the same speed but with a timbrally somewhat different artifacts like the one at 1800MHz. 3) When using mme, or DirectX or any other non-ASIO playback format in Windows, no matter what the latency in the hdsp config tool, the sound output is flawless. 4) I also read that some of the 2.6.2 Linux kernel patches were incorporated to fix the fact that Bios represents the CPU speed (via ACPI?) as 1600MHz which is apparent in the Windows if one
[Alsa-devel] RE: Major problem with RME HDSP/Multiface and a 64-bit AMD laptop
Forgot to ask two more questions: 1) How can I go about testing the throughput of my pcmcia cardbus in order to see whether it is the culprit? 2) If the cardbus proves to be the problem, is there a way to hook-up hdsp directly via Firewire port, or is there perhaps an adaptor that converts either USB 2.0 or Firewire into pcmcia cardbus? Many thanks! Ivica Ico Bukvic, composer multimedia sculptor http://meowing.ccm.uc.edu/~ico/ --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
