Re: [Alsa-devel] Patch to fix LIN_OUT1 on Audigy2 cards (+ others)
Andrew de Quincey: Cool, I'll add that to my list BTW, attached is my current state of analysis of the mixer devices.. not complete yet (been very busy recently). If you can be bothered, can you confim what I've got so far? I've obviously had little success being bothered so far... I guess I'll post what I can right now. * Tone Switch to enable tone controls Umuted: enabled Muted: disabled * Bass Controls output Bass. * Treble Controls output Treble. These work here too. ? Surround IIRC, with aplay -D rear out.dat, this will control its volume. * Wave Master control volume of PCM data (and ONLY PCM data). Volume controls work. Controls my line1 and spdif out. BTW, do you know how I can output to the rca spdif out (Optical IEC958), _without_ outputting to anything else? I want to run my iiwusynth output through an effects processor but I can't figure out how to do it properly without feedback. mjr$ aplay -D iec958 out.dat ALSA lib pcm_hw.c:1078:(snd_pcm_hw_open) open /dev/snd/pcmC1D3p failed: No such device is one thing i tried without success. Unrelated: it's interesting that my audigy1's line1 output was quite a bit louder than the audigy2's, though it had a worse noise floor even when turned down to a comparable level. Weirdly, the OSS driver for it was softer, about comparable to my audigy2 right now. ? Wave Center ? Wave LFE ? Wave Surround All working here. ? Music ? Music Capture * Line Controls input from LIN_IN on card. Mute/unmute works. Volume controls work. Needs to be selected as a capture input. * Line2 Controls input from Line 2/Mic 2 on drive. Volume controls work. ? Line2 Capture * CD Controls input from CD_IN on card. Mute does not work. Volume does not work. Needs to be selected as a capture input. Volume is controlled by Capture+AC97. ? Mic ? Mic Boost ? Mic Select ? Video ? Phone ? PC Speaker * Aux Controls input from AUX_IN on card. Volume does not work. Needs to be selected as a capture input. Volume is controlled by Capture+AC97. * Aux2 Controls input from Aux In 2 on drive. Volume controls work. ? Aux2 Capture ? Mono Out All untested, sorry. * Capture Provides master control for all capturing. Volume control works and affects all captures. Select as a capture device to enable capture. Deselect to disable all capturing. I've been able to capture from spdif without turning up this slider... I'm not really sure about the specifics now. ? Mix ? Mix Mono ? AC97 ? AC97 Capture * Audigy Analog/Digital Output Jack Controls switch between output on LIN_OUT1, LIN_OUT2, LIN_OUT3 and Digital-out-jack on card. Needs the special creative speakers to take advantage of digital (Audigy/2 cannot encode AC3) Can also passthrough pre-encoded AC3 (e.g. from a DVD) Unmuted: Analogue output Muted: Digital output through * Audigy CD Controls input from CD_SPDIF connector. ? Audigy CD Capture ? External Amplifier Power Down All untested. ? Optical IEC958 ? Optical IEC958 Capture These are my audigy-drive rca spdif sliders. ? RCA SPDIF ? RCA SPDIF Capture I don't know what these are supposed to do, given the above... Oh, and MIDI input is still an unresolved issue. No interrupts, etc, through the gameport and the drive. Output works on both. Maybe a problem with snd_emu10k1_intr_enable()? Without datasheets I am totally hopeless... --- 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] Re: Extended API: Constructors and alloca()
Hi Lars,
[i forwarded this to alsa-devel, since i'd like to keep the development
as open as possible.]
BACKGROUND:
we're trying to define a C++ library set on the top of alsa-lib.
my idea is to provide this library separately from alsa-lib itself,
i.e. as a c++ wrapper library (just like the relationship between
libgtk++ and libgtk).
At Thu, 20 Mar 2003 19:52:54 +0100,
Lars Hamren wrote:
Hi,
we talked during the econference about documentation and about a new
API. I have been looking a the API part since I came home.
Unfortunately, alloca() cannot be used in a constructor, since the
memory will be deallocated when the constructor exits. Instead I think
that a good solution is to embed the data structure from the
standard library into into each class:
# include stdio.h
# include string.h
# define ATTRIBUTE_UNUSED
namespace AlsaStandardLibrary {
#include src/control/control_local.h
};
namespace Alsa {
class Control {
public:
Control() { memset(_data, 0, sizeof _data); }
private:
AlsaStandardLibrary::snd_ctl_t _data;
};
}
int main()
{
Alsa::Control c;
printf(c = %08lX\n, (long)c);
}
Using this implementation there is no extra memory allocation, and
alloca() is no longer necessary.
however, by this implementation, the private headers are still
referred from the public headers. IMO, this is the very weakpoint of
c++. you cannot hide the private members at all...
i believe putting the private things to the public place is not
suitable from the viewpoint of the design of alsa-lib.
By padding the class definition with a few extra longs, the size could
stay fixed even if there are small changes to alsalib structure
definitions.
it's pragmatic but still the problem remains how to manage the private
header files.
One alternative is to use a pointer instead of embedde data, but that
would require more use of malloc and free.
i think this is not so bad as imagined.
you can put a reference counter and a copy constructor to reuse the
allocated object.
in most cases, the instances are not always necessarily on stack.
in addition to the fact some instances are big, in c programs, we've
used alloca in many places just because it doesn't need the manual
free(). in c++, it's no longer problem.
also, the instances are often used for long term, so the total impact
wouldn't be too much.
the only flaw of this method is that it forces to allocate a temporary
data such as pcm_status in advance. otherwise calling malloc at API
call will result in a sleep, which is critical for a realtime app.
Another alternative is to embed a `char _data[BIG_ENOUGH];' but that
would require a cast for every use of _data.
hmm... i will not take this...
A third alternative is to derive:
class Control : public AlsaStandardLibrary::snd_ctl_t {
public:
Control() { memset(this, 0, sizeof *this); }
};
which is more or less equivalent to embedding in this case. I may
settle for this.
It would be a good thing if the necesary structs (snd_ctl_t, et c.)
were available in an unofficial include file in the library.
THIS is the very question.
so far, in the implementation of alsa-lib, we have been trying to hide
this. the all strucs are suppose to be opaque (except for some
trivial cases).
putting the struct in public (even though it's unofficial) breaks this
policy.
Takashi
---
This sf.net email is sponsored by:ThinkGeek
Welcome to geek heaven.
http://thinkgeek.com/sf
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] How do I perform non-DMA transfers in an interrupt handler?
Hi all, I face the following problem: The card I'm writing a driver for (SAM9707 based) doesn't support any form of DMA transfer. It requires you to transfer the PCM data through a 'rep outsw' like mechanism. It raises an interrupt when it needs new data. The transfer flow is as follows: 1) allocate buffer on card 2) start playback 3) card raises interrupt 4) transfer block of data in interrupt handler 5) wait for next interrupt - 4 How do I implement this in ALSA? After reading the 'Writing an ALSA driver' document a few times, I still cannot figure out how to do this. Should I use the copy/silence callbacks? Or can I access the PCM buffer from within the interrupt handler? I'm currently using 'concept' code from Uros Bizjak, and the interrupt handler looks like this: (I removed irrelevant pieces) substream = voice-substream; runtime = substream-runtime; hwoff = runtime-hw_ptr_interrupt; hwbuf = (u16 *) runtime-dma_area; hwbuf += (frames_to_bytes(runtime, hwoff) 1); /* word transfer count */ wcount = snd_pcm_lib_period_bytes(substream); wcount = 1; /* transfer to/from sam9407 buffers */ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) sam-writeData16Burst(sam, hwbuf, wcount); else sam-readData16Burst(sam, hwbuf, wcount); snd_sam9407_command(sam, NULL, SAM_END_XFER, voice-channel, 1, NULL, 0, -1); /* update hardware pointer mirror */ voice-hwptr = runtime-hw_ptr_interrupt + runtime-period_size; snd_pcm_period_elapsed(substream); But I'm not sure if this is correct. What should I use here? Is there a card driver that I can refer to that uses the same mechanism? Pieter --- 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] How do I perform non-DMA transfers in an interrupthandler?
On Fri, 21 Mar 2003, Pieter Palmers wrote: Hi all, I face the following problem: The card I'm writing a driver for (SAM9707 based) doesn't support any form of DMA transfer. It requires you to transfer the PCM data through a 'rep outsw' like mechanism. It raises an interrupt when it needs new data. The transfer flow is as follows: 1) allocate buffer on card 2) start playback 3) card raises interrupt 4) transfer block of data in interrupt handler 5) wait for next interrupt - 4 How do I implement this in ALSA? After reading the 'Writing an ALSA driver' document a few times, I still cannot figure out how to do this. Should I use the copy/silence callbacks? Or can I access the PCM buffer from within the interrupt handler? I'm currently using 'concept' code from Uros Bizjak, and the interrupt handler looks like this: (I removed irrelevant pieces) substream = voice-substream; runtime = substream-runtime; hwoff = runtime-hw_ptr_interrupt; hwbuf = (u16 *) runtime-dma_area; hwbuf += (frames_to_bytes(runtime, hwoff) 1); /* word transfer count */ wcount = snd_pcm_lib_period_bytes(substream); wcount = 1; /* transfer to/from sam9407 buffers */ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) sam-writeData16Burst(sam, hwbuf, wcount); else sam-readData16Burst(sam, hwbuf, wcount); snd_sam9407_command(sam, NULL, SAM_END_XFER, voice-channel, 1, NULL, 0, -1); /* update hardware pointer mirror */ voice-hwptr = runtime-hw_ptr_interrupt + runtime-period_size; snd_pcm_period_elapsed(substream); But I'm not sure if this is correct. What should I use here? Is there a card driver that I can refer to that uses the same mechanism? This code is ok. It might use probably a little bit better interrupt resolution to sync the DMA ring buffer with hardware more precisely (I mean use the transfer size in interrupt less than the period size). You don't need to use extra copy and silence when the DMA ring buffer has not a special sample order (something other than interleaved and non-interleaved). 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: [Alsa-devel] SoundCard compatibility question
That card may not even be full duplex. For a very cheap, compatible card you can use an Ensoniq Audio PCI. This is 16 bit 48KHz. I've done some decent two channel recording with one of those. There are a couple of decent two channel 24 bit 96KHz cards based on the envy24 chipset that run about $130 to $180 US at musician's Friend. Here are a couple of examples. http://www.musiciansfriend.com/srs7/sid=030320132900024117199122901257/search/g=live/detail/base_id/52845 http://www.musiciansfriend.com/srs7/sid=030320132900024117199122901257/search/g=live/detail/base_id/52399 If you need more than two channels I would recommend the Delta 44 or 66 (again, envy24 chipset which I highly recommend). http://www.musiciansfriend.com/srs7/sid=030320132900024117199122901257/search/g=live/detail/base_id/52398 http://www.musiciansfriend.com/srs7/sid=030320132900024117199122901257/search/g=live/detail/base_id/52397 Hope that helps. Jan On Thu, 2003-03-20 at 14:48, Pete Barnard wrote: I have just installed Red Hat Linux 7.3 on my pc at work and will be installing the ALSA drivers. However, the sound card is described as a SoundMax integrated Audio (I don't really know much about this card and cannot find it on the ALSA soundcard matrix). I have read that it is a SoundBlaster compatible card but I haven't had this confirmed. Does anybody have any suggestions as to how I would get ALSA to work with this card? for example, what lines do I need to put in the /etc/modules.conf file? and what options do I need to type when I do a ./configure for the drivers? Are there any external drivers that I need to download etc? Failing all this - will I have to replace it with another card that is listed on the ALSA soundcard matrix ?? Regards, Pete --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Extended API: Constructors and alloca()
It would be a good thing if the necesary structs (snd_ctl_t, et c.) were available in an unofficial include file in the library. THIS is the very question. so far, in the implementation of alsa-lib, we have been trying to hide this. the all strucs are suppose to be opaque (except for some trivial cases). putting the struct in public (even though it's unofficial) breaks this policy. i (and i hope many other ALSA users/developers) would scream very loudly if we moved from this design/policy. it has been critical and central to success in stabilizing the API from the perspective of applications. it has worked for Xlib for a long time, it has worked for us for a year or more, and we should not change this. making the change proposed by lars would open us up to major binary compatibility issues as alsa evolves. --- 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] How do I perform non-DMA transfers in an interrupthandler?
Jaroslav Kysela wrote:
On Fri, 21 Mar 2003, Pieter Palmers wrote:
Hi all,
I face the following problem: The card I'm writing a driver for (SAM9707
based) doesn't support any form of DMA transfer. It requires you to
transfer the PCM data through a 'rep outsw' like mechanism. It raises an
interrupt when it needs new data. The transfer flow is as follows:
1) allocate buffer on card
2) start playback
3) card raises interrupt
4) transfer block of data in interrupt handler
5) wait for next interrupt - 4
How do I implement this in ALSA? After reading the 'Writing an ALSA
driver' document a few times, I still cannot figure out how to do this.
Should I use the copy/silence callbacks? Or can I access the PCM buffer
from within the interrupt handler? I'm currently using 'concept' code
from Uros Bizjak, and the interrupt handler looks like this:
(I removed irrelevant pieces)
substream = voice-substream;
runtime = substream-runtime;
hwoff = runtime-hw_ptr_interrupt;
hwbuf = (u16 *) runtime-dma_area;
hwbuf += (frames_to_bytes(runtime, hwoff) 1);
/* word transfer count */
wcount = snd_pcm_lib_period_bytes(substream);
wcount = 1;
/* transfer to/from sam9407 buffers */
if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK)
sam-writeData16Burst(sam, hwbuf, wcount);
else
sam-readData16Burst(sam, hwbuf, wcount);
snd_sam9407_command(sam, NULL, SAM_END_XFER,
voice-channel, 1, NULL, 0, -1);
/* update hardware pointer mirror */
voice-hwptr = runtime-hw_ptr_interrupt + runtime-period_size;
snd_pcm_period_elapsed(substream);
But I'm not sure if this is correct.
What should I use here?
Is there a card driver that I can refer to that uses the same mechanism?
This code is ok. It might use probably a little bit better interrupt
resolution to sync the DMA ring buffer with hardware more precisely (I
mean use the transfer size in interrupt less than the period size).
Currently I'm trying to get it working. Later on I'll optimize the
transfers, but the SAM is a pretty strange chip.
Maybe you have some suggestions on how to implement this...
This is a piece of my conversation with Gerd Rausch, the OSS driver
developer for the SAM based cards:
|Pieter Let me rephrase the question: if I end a transfer with
an END_XFER
|Pieter command after e.g. 1024 words, will the firmware raise
another interrupt
|Pieter to retrieve the next block of data? Or am I supposed to
transfer blocks
|Pieter of 8192 words at once?
|
|I ran a few tests today, with a result you might not appreciate:
|I tried to figure out how picky the firmware is about the correct
|amount of data transferred.
|And the result I've got was:
|It is very picky !
|You need to allocate exactly the number of words you are intending to
|transfer plus the additional magic 16 words overhead.
|Then, with each interrupt incoming, you need to finish the transfer
|with exactly one END_XFER and wait for the next interrupt.
|Every other combination you listed did not work.
The background on this is that you allocate a buffer of e.g. 8192 words
on the card. You then open the channel and start playback. The card then
raises interrupts when it needs data. The question presented above is
how much data is to be transfered each time the SAM raises interrupt.
I currently fixed the driver parameters like this:
static snd_pcm_hardware_t snd_sam9407_playback =
{
(...)
.buffer_bytes_max =SAM_MAX_BUFFER_SIZE 1,
.period_bytes_min =((SAM_MAX_BUFFER_SIZE) 1),
.period_bytes_max =((SAM_MAX_BUFFER_SIZE) 1),
(...)
};
in an attempt to get things working.
The documentation on the card its firmware is very incomplete (almost
absent) and all knowledge is obtained by TrialError(TM) and reverse
engineering windows drivers. So my first priority is getting ANY output
from the card. In a next step I'll try and optimize it.
You don't need to use extra copy and silence when the DMA ring buffer has
not a special sample order (something other than interleaved and
non-interleaved).
OK
Thanks!
Pieter
---
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] How do I perform non-DMA transfers in an interrupt handler?
At Fri, 21 Mar 2003 13:31:02 +0100 (CET), Jaroslav wrote: On Fri, 21 Mar 2003, Pieter Palmers wrote: Hi all, I face the following problem: The card I'm writing a driver for (SAM9707 based) doesn't support any form of DMA transfer. It requires you to transfer the PCM data through a 'rep outsw' like mechanism. It raises an interrupt when it needs new data. The transfer flow is as follows: 1) allocate buffer on card 2) start playback 3) card raises interrupt 4) transfer block of data in interrupt handler 5) wait for next interrupt - 4 How do I implement this in ALSA? After reading the 'Writing an ALSA driver' document a few times, I still cannot figure out how to do this. Should I use the copy/silence callbacks? Or can I access the PCM buffer from within the interrupt handler? I'm currently using 'concept' code from Uros Bizjak, and the interrupt handler looks like this: (I removed irrelevant pieces) substream = voice-substream; runtime = substream-runtime; hwoff = runtime-hw_ptr_interrupt; hwbuf = (u16 *) runtime-dma_area; hwbuf += (frames_to_bytes(runtime, hwoff) 1); /* word transfer count */ wcount = snd_pcm_lib_period_bytes(substream); wcount = 1; /* transfer to/from sam9407 buffers */ if (substream-stream == SNDRV_PCM_STREAM_PLAYBACK) sam-writeData16Burst(sam, hwbuf, wcount); else sam-readData16Burst(sam, hwbuf, wcount); snd_sam9407_command(sam, NULL, SAM_END_XFER, voice-channel, 1, NULL, 0, -1); /* update hardware pointer mirror */ voice-hwptr = runtime-hw_ptr_interrupt + runtime-period_size; snd_pcm_period_elapsed(substream); But I'm not sure if this is correct. What should I use here? Is there a card driver that I can refer to that uses the same mechanism? This code is ok. It might use probably a little bit better interrupt resolution to sync the DMA ring buffer with hardware more precisely (I mean use the transfer size in interrupt less than the period size). in the case above, how about the timing? if the data transfer from memory to the hardware is asynchronous with the actually played samples (i.e. data is transferred to the h/w buffer and pending there), which value should pointer() callback return? applications often refer to the hw_ptr as the sample position at which DMA is running or has processed. but if snd_pcm_period_elapsed() is issued soon after the buffer transfer (not the buffer process), this doesn't correspond to the real time (although this still will work in most cases). Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] dsnoop, dshare and dmix plugins
On Fri, 21 Mar 2003, Patrick Shirkey wrote: Fernando Pablo Lopez-Lezcano wrote: It would be nice that the user not need to type magic numbers into a configuration file, unique or not. I don't know what it involves, but it would make using the configuration file much easier. Even nicer is if this could be embedded like the dmix was eventually so that it is unnecessary to use the .asoundrc :) It's a little problematic to add dshare to the global configuration file. I've added the dsnoop plugin just now. 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: [Alsa-devel] SoundCard compatibility question
Hallo, Pete Barnard hat gesagt: // Pete Barnard wrote: I have just installed Red Hat Linux 7.3 on my pc at work and will be installing the ALSA drivers. However, the sound card is described as a SoundMax integrated Audio (I don't really know much about this card and cannot find it on the ALSA soundcard matrix). I have read that it is a SoundBlaster compatible card but I haven't had this confirmed. Does anybody have any suggestions as to how I would get ALSA to work with this card? for example, what lines do I need to put in the /etc/modules.conf file? and what options do I need to type when I do a ./configure for the drivers? Are there any external drivers that I need to download etc? With a lot of cards, and most onboard chipsets, it is important to know, which chipset is used. You can try to find this out with lspci. It prints a long list that you should search for Multimedia or Audio adapters. Then look for a module called somehow like it and try to modprobe it. ciao -- Frank Barknecht _ __footils.org__ --- 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] dsnoop, dshare and dmix plugins
At Fri, 21 Mar 2003 13:56:50 +0100 (CET), Jaroslav wrote: On Fri, 21 Mar 2003, Patrick Shirkey wrote: Fernando Pablo Lopez-Lezcano wrote: It would be nice that the user not need to type magic numbers into a configuration file, unique or not. I don't know what it involves, but it would make using the configuration file much easier. Even nicer is if this could be embedded like the dmix was eventually so that it is unnecessary to use the .asoundrc :) It's a little problematic to add dshare to the global configuration file. it would be cool if we have the dynamic voice-assignment function in dshare... just a thought. Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: Extended API: Constructors and alloca()
At Fri, 21 Mar 2003 07:51:41 -0500, Paul Davis wrote: It would be a good thing if the necesary structs (snd_ctl_t, et c.) were available in an unofficial include file in the library. THIS is the very question. so far, in the implementation of alsa-lib, we have been trying to hide this. the all strucs are suppose to be opaque (except for some trivial cases). putting the struct in public (even though it's unofficial) breaks this policy. i (and i hope many other ALSA users/developers) would scream very loudly if we moved from this design/policy. it has been critical and central to success in stabilizing the API from the perspective of applications. it has worked for Xlib for a long time, it has worked for us for a year or more, and we should not change this. making the change proposed by lars would open us up to major binary compatibility issues as alsa evolves. agreed, the compatibility must be kept. as mentioned in the last mail, our initial plan is to make a c++ library which covers the existing alsa-lib, that is, alsa-lib++. alsa-lib API (in C) won't be changed by this, i promise you. Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: Waveterminal 192M Envy24HT
Hi, Frank Neumann of the linux audio devel list has been kind enough to send the email address of the contact he made at Musikmesse 2002, this is the guy who sent the Wamibox code over (http://eca.cx/lad/2002/06/0167.html) its [EMAIL PROTECTED] I suggest that if we dont recieve a response from your earlier email to egosys we should try this guy. regards, Chris --- 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] alsaconf -L - where's Waldo?
Hi, The --help option says that I can get a log file from alsaconf using the -L option. If I look in /tmp while alsaconf is running, I see some files, but when alsaconf has finished, the files are gone... [EMAIL PROTECTED] mark]$ ls /tmp alsaconf.3nMgvm alsaconf.txNTFm ksocket-mark orbit-mark ssh-XX7Jn9me alsaconf.Ef6KCm kde-mark mcop-mark ssh-XX1CS1IB ssh-XXIbrHpS [EMAIL PROTECTED] mark]$ ls /tmp kde-mark ksocket-mark mcop-mark orbit-mark ssh-XX1CS1IB ssh-XX7Jn9me ssh-XXIbrHpS [EMAIL PROTECTED] mark]$ Is this file possibly put somewhere else? I'm trying to figure out why alsaconf is complaining about this card. Loading driver.. Starting sound driver snd-hdsp /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters. You may find more information in syslog or the output from dmesg init_module: No such device /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o: insmod /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o failed /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o: insmod snd-hdsp failed [FAILED] Setting default volumes.. === Now ALSA is ready to use. For adjustment of volumes, please use alsamixer or gamix. Have a lot of fun! [EMAIL PROTECTED] etc]# --- 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] alsaconf -L - where's Waldo?
At 21 Mar 2003 05:50:47 -0800, Mark Knecht wrote: Hi, The --help option says that I can get a log file from alsaconf using the -L option. If I look in /tmp while alsaconf is running, I see some files, but when alsaconf has finished, the files are gone... yep, they are temporary working directories. [EMAIL PROTECTED] mark]$ ls /tmp alsaconf.3nMgvm alsaconf.txNTFm ksocket-mark orbit-mark ssh-XX7Jn9me alsaconf.Ef6KCm kde-mark mcop-mark ssh-XX1CS1IB ssh-XXIbrHpS [EMAIL PROTECTED] mark]$ ls /tmp kde-mark ksocket-mark mcop-mark orbit-mark ssh-XX1CS1IB ssh-XX7Jn9me ssh-XXIbrHpS [EMAIL PROTECTED] mark]$ Is this file possibly put somewhere else? I'm trying to figure out why alsaconf is complaining about this card. /tmp/alsaconf.log is created only when the legacy cards are probed. it's for a deubgging purpose only... Loading driver.. Starting sound driver snd-hdsp /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters. You may find more information in syslog or the output from dmesg init_module: No such device /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o: insmod /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o failed /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o: insmod snd-hdsp failed do you already have another sound module? alsaconf can configure only the first device (i.e. index=0). configuring more than one card is not supported yet. Takashi --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] possible ALSA bug/feature (was: important recording broke. why?)(fwd)
Hi, first please read the mail to ecasound-list below. It seems that with newer ALSA versions, snd_pcm_read[in]() sometimes returns -EIO even though documentation says nothing about this. After some testing this seems to not happen on direct hw-access, only with the pcm_plugin. The EIO comes from snd_pcm_wait(). Is this a bug or or a feature? Btw; the error does not seem to be critical. If I handle the EIO the same way as EPIPE (i.e. run xrun handling code), the recording will continue fine. -- Forwarded message -- Date: Fri, 21 Mar 2003 12:45:53 + From: The Eye [EMAIL PROTECTED] Reply-To: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: [ecasound] important recording broke. why? Yesterday I had an important recording (a radio-show I did) ... I had it scheduled via at, the same command I always use, i.e. ecasound -b:2048 -z:intbuf -z:db,20 -r -ev -t:8400 -f:s16_le,2,44100 -i:alsa,default -o:laermraw.raw OK, this has always worked ... now I read my mails today, and what do I see in my inbox? the following: * ecasound v2.2.2-pre1 (C) 1997-2003 Kai Vehmanen - [ Session created ] -- - [ Chainsetup created (cmdline) ] - (eca-chainsetup-parser) Setting buffersize to (samples) 2048. (eca-chainsetup-parser) Enabling extra buffering on realtime devices. (eca-chainsetup-parser) Using double-buffer of 20 sample frames. (eca-chainsetup) Raised-priority mode enabled. (prio:50) (eca-chainsetup-parser) Set processing time to 8400.00. - [ Connecting chainsetup ] (eca-chainsetup) 'rt' buffering mode selected. (eca-chainsetup) Audio object alsa, mode read. (audio-io) Format: s16_le, channels 2, srate 44100, interleaved. (eca-chainsetup) Audio object laermraw.raw, mode read/write. (audio-io) Format: s16_le, channels 2, srate 44100, interleaved. - [ Chainsetup connected ] - (eca-controller) Connected chainsetup: command-line-setup. - [ Controller/Starting batch processing ] - - [ Engine init - Driver start ] --- (eca-engine) Prefilling i/o buffers. (audioio-alsa) warning! playback overrun - samples lost! Break was at least 0.05 ms long. (audioio-alsa) Read error! Stopping operation. Warning: DBC_REQUIRE failed - samples_read = 0, samplebuffer.cpp, 757. sh: line 61: 2821 Segmentation fault ecasound -b:2048 -z:intbuf -z:db,20 -r -ev -t:8400 -f:s16_le,2,44100 -i:alsa,default -o:laermraw.raw is this a bug? btw this happened after approx. 2 minutes of recording .. since I myself wasn't present (I was in the studio, doing the radio show that should have been recorded), the recording is of course lost .. darn! -- Michael Hellwig aka The Eye olymp.idle.at admin check out http://homepage.uibk.ac.at/~csaa5128 for gpg public key and don't hesitate to look at http://laerm.or.at -- To unsubscribe send message 'unsubscribe' in the body of the message to [EMAIL PROTECTED]. --- 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] inegrating a driver into the ALSA tree
At Wed, 19 Mar 2003 14:11:08 +0100, Pieter Palmers wrote: Hi, I'm currently writing a driver for the Guillemot MaxiStudio ISIS card, and I have the following question: how do I integrate my driver into the ALSA tree? I'm totaly infamiliar with the autoconf/automake stuff... For the moment I only need it on my own machine, so I compile it separately. But in a later stage I'd like to distribute some beta releases, and in the end it should end up in the ALSA distribution I guess. (hmm, i have a dejavu; the same question appeared sometime ago. this should really go to HOWTO :) suppose that you'll create a new PCI driver xyz. you'll need to add the following: 1. modify alsa-driver/pci/Makefile * if you have a single file xyz.c for a new driver snd-xyz, add the following two lines snd-xyz-objs := xyz.o extra-obj-$(CONFIG_SND_XYZ) += snd-xyz.o * if you have several files for a new driver(s), add a new directory name (xyz) to extra-subdir-y list extra-subdir-y := pdplus vx222 xyz and under the directory xyz, create a Makefile TOPDIR = ../.. include $(TOPDIR)/toplevel.config include $(TOPDIR)/Makefile.conf TOPDIR = $(MAINSRCDIR) snd-xyz-objs := xyz.o abc.o def.o obj-$(CONFIG_SND_XYZ) += snd-xyz.o include $(TOPDIR)/Rules.make 2. modify alsa-driver/acore/Makefile define the dependent modules. obj-$(CONFIG_SND_XYZ) += snd.o ... if the driver supports pcm, snd-pcm.o, snd-timer.o and snd-page-alloc.o will be needed. for rawmidi, snd-rawmidi.o, and for opl3, snd-hwdep.o are needed. these are also related to the sequencer stuff. you'll need to modify alsa-driver/acore/seq/Makefile (and acore/seq/instr/Makefile for opl3 in addition). 3. modify alsa-driver/utils/Modules.dep add the module definition for configure, here. * if you have snd-xyz on pci directory, %dir linux/sound/pci |snd-azt3328 snd-pcm snd-mpu401-uart snd-opl3-lib snd-opl3-synth |snd-xyz snd-pcm ... * if you have a separate directory pci/xyz, %dir linux/sound/pci/xyz |snd-xyz snd-pcm ... 4. run cvscompile script to re-generate the configure script and build the whole stuff again. ciao, Takashi --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [PATCH] azt3328.c and maestro3.c cleanup
At Tue, 18 Mar 2003 17:03:12 +0100, Andreas Mohr wrote: Hi all, - fix typo and change comment for Inspiron's Maestro 3 - update azt3328.c to mention sound improvements with newer PCI168 revisions applied to cvs. thanks! Takashi --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] NEW hdsp 9652 problems - {WAS: alsaconf -L - where's Waldo?)
Takashi, I have two sound devices (on-board Via device and an RME HDSP 9652) but I only want to configure the RME. Currently alsaconf finds the RME, attempts to install the drivers, and then the drivers fail saying they cannot find the cards. I had hoped that possibly the log file would give me more information on why. I suppose it will not if it's only for ISA devices. (BTW - alsaconf does find this Via chip and can configure it correctly.) I think that the --help for alsaconf should make this more clear. Currently it says: -L|--log logging on /tmp/alsaconf.log No idea it only covers ISA devcies. OK, so I start with a clean /etc/modules.conf looking like this: alias parport_lowlevel parport_pc alias eth0 bcm4400 alias usb-controller ehci-hcd alias usb-controller1 usb-uhci lspci -v shows: SNIP 00:0e.0 Multimedia audio controller: Xilinx, Inc. RME Hammerfall DSP (rev 68) Flags: bus master, medium devsel, latency 32, IRQ 10 Memory at e980 (32-bit, non-prefetchable) [size=64K] SNIP I then run alsaconf. It shows the hdsp and the via82xx. I choose the hdsp and get the following: Loading driver.. Starting sound driver snd-hdsp /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o: Hint: insmod errors can be caused by incorrect module parameters, including invalid IO or IRQ parameters. You may find more information in syslog or the output from dmesg init_module: No such device /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o: insmod /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o failed /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o: insmod snd-hdsp failed [FAILED] Setting default volumes.. === Now ALSA is ready to use. For adjustment of volumes, please use alsamixer or gamix. Have a lot of fun! [EMAIL PROTECTED] etc]# modules.conf now looks like: alias parport_lowlevel parport_pc alias eth0 bcm4400 alias usb-controller ehci-hcd alias usb-controller1 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=1 device_mode=0666 options snd-hdsp index=0 # --- END: Generated by ALSACONF, do not edit. The card is not recognized on reboot either. dmesg shows a log string of these messages: Hammerfall memory allocator: buffers allocated for 1 cards RME Hammerfall-DSP: no cards found Hammerfall memory allocator: buffers allocated for 1 cards RME Hammerfall-DSP: no cards found Now, this all worked fine on the previous 2.4.19-1.ll kernel from the PlanetCCRMA site **BEFORE** I updated firmware on the HDSP 9652 for new Win XP driver support. After updating firmware for the card, the alsaconf program I had for the 2.4.19-1.ll kernel no longer recognized the card at all and cannot write anything in modules.conf. I have a new PC in my studio, using a newer kernel from the Planet not released widely yet. (2.4.20-1.12.ll.acpi) The kernel is dated Sunday, Feb. 2nd. The alsa RPM is dated Feb. 18th and appears to be alsa 0.9.0-45, if that makes sense. I understand some of this might be Fernando's numbering system for the Planet. The alsaconf that comes with this kernel recognizes the card, but the driver doesn't load and says there's no card. Chicken egg problem apparently... Thanks for any help you can provide. Cheers, Mark On Fri, 2003-03-21 at 05:59, Takashi Iwai wrote: At 21 Mar 2003 05:50:47 -0800, Mark Knecht wrote: Hi, The --help option says that I can get a log file from alsaconf using the -L option. If I look in /tmp while alsaconf is running, I see some files, but when alsaconf has finished, the files are gone... yep, they are temporary working directories. [EMAIL PROTECTED] mark]$ ls /tmp alsaconf.3nMgvm alsaconf.txNTFm ksocket-mark orbit-mark ssh-XX7Jn9me alsaconf.Ef6KCm kde-mark mcop-mark ssh-XX1CS1IB ssh-XXIbrHpS [EMAIL PROTECTED] mark]$ ls /tmp kde-mark ksocket-mark mcop-mark orbit-mark ssh-XX1CS1IB ssh-XX7Jn9me ssh-XXIbrHpS [EMAIL PROTECTED] mark]$ Is this file possibly put somewhere else? I'm trying to figure out why alsaconf is complaining about this card. /tmp/alsaconf.log is created only when the legacy cards are probed. it's for a deubgging purpose only... Loading driver.. Starting sound driver snd-hdsp /lib/modules/2.4.20-1.12.ll.acpi/kernel/drivers/sound/pci/rme9652/snd-hdsp.o: Hint: insmod errors can be
Re: [Alsa-devel] Fwd: arecord bug?
At Wed, 19 Mar 2003 22:35:17 +0900, Jon Ellis wrote: On Wednesday, March 19, 2003, at 09:08 PM, Justin Cormack wrote: On Wed, 2003-03-19 at 09:49, Jon Ellis wrote: On Tuesday, March 18, 2003, at 10:29 PM, Takashi Iwai wrote: i guess it reached to 32bit int limit (401*60*4*44100). so far, aplay/arecord doesn't support more than size_t max, which is 32bit on i386. Yep, that was my guess too. Is this something anyone is interested in fixing? A couple of ideas: i) move up to 64bits ii) start using segments If anyone who knows the code is interested in working with me i'd be happy to help find the right fix. Not sure that i have the time to learn the codebase from scratch right now... Have you tried recompiling it with -D_FILE_OFFSET_BITS=64 -D_LARGEFILE_SOURCE in the CFLAGS? This should just work unless there is somethong broken in the code. i'll give it a try... my suspicion is that it wont work because it's the number of... er, frames (? I'm not sure i'm using the correct names for things) that is overflowing size_t. I'd be happy to be wrong. it's the count in bytes. anyway, i fixed the relevant part on cvs. now arecord allows you to capture the unlimited size in the raw mode. i've not tested this yet (no time :) also fixed a bug in the capture to stdout in WAV mode. it's restricted to 32bit signed int due to the RIFF chunk. it would be possible to record longer than creating more chunks but arecord doesn't do that (yet). ciao, Takashi --- This SF.net email is sponsored by: Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] NEW hdsp 9652 problems - {WAS: alsaconf -L -where's Waldo?)
On Fri, 2003-03-21 at 16:17, Mark Knecht wrote: Takashi, I have two sound devices (on-board Via device and an RME HDSP 9652) but I only want to configure the RME. Currently alsaconf finds the RME, attempts to install the drivers, and then the drivers fail saying they cannot find the cards. I had hoped that possibly the log file would give me more information on why. I suppose it will not if it's only for ISA devices. (BTW - alsaconf does find this Via chip and can configure it correctly.) You need a more recent version of the driver, probably the cvs version for this card. The configurator probably checks the PCI id but not the revision nuumber. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] NEW hdsp 9652 problems - {WAS: alsaconf -L -where's Waldo?)
On Fri, 2003-03-21 at 08:39, Justin Cormack wrote: On Fri, 2003-03-21 at 16:17, Mark Knecht wrote: Takashi, I have two sound devices (on-board Via device and an RME HDSP 9652) but I only want to configure the RME. Currently alsaconf finds the RME, attempts to install the drivers, and then the drivers fail saying they cannot find the cards. I had hoped that possibly the log file would give me more information on why. I suppose it will not if it's only for ISA devices. (BTW - alsaconf does find this Via chip and can configure it correctly.) You need a more recent version of the driver, probably the cvs version for this card. The configurator probably checks the PCI id but not the revision nuumber. Justin, Thanks for the reply. It makes sense to me, however, since I use the PlanetCCRMA flow, and alsa is supplied as an RPM, I have no way (that I know of) to just get a new driver, compile it and try it out. I need a new RPM, I think. Thanks for the ideas! Cheers, Mark --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Need for a new ALSA developer?
Hello everybody, My name is Robert and I'm very much interested in working on ALSA Project with you. I primarily would like to develop a new driver for a souncard, which is not supported by ALSA yet, perhaps some USB stuff from Midiman? Please let me know what are the possibilities for me to be involved. Thanks Robert Vetter --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] NEW hdsp 9652 problems - {WAS: alsaconf -L -where's Waldo?)
On Fri, 2003-03-21 at 09:45, Paul Davis wrote: Now, this all worked fine on the previous 2.4.19-1.ll kernel from the PlanetCCRMA site **BEFORE** I updated firmware on the HDSP 9652 for new Win XP driver support. After updating firmware for the card, the alsaconf program I had for the 2.4.19-1.ll kernel no longer recognized the card at all and cannot write anything in modules.conf. you cannot use the current ALSA driver with the new firmware. i submitted a patch to handle the new firmware, but it has not been put into CVS yet. meanwhile, thomas charbonnel has extended the work i did and added some more stuff, and so we are working on a mega-patch that fixes lots of issues with full H-DSP support. once thomas gets his tasklet problems fixed (for MIDI I/O without affecting PCM latency), we'll submit the patch again. --p Paul, Well, I guess thanks then for saving the rest of my vacation Friday from being a total waste of time. I took the day off to focus on getting this Alsa stuff going. Now I find I cannot. Too bad for me I guess. I guess I will take my vacation day and rewire my studio to get this Linux box out of the audio path completely. In a few hours I'll be back to where I was last September, other than using Linux for email now, it just doesn't seem like a positive 6 months. Not your fault. All mine for even trying to use this Linux stuff seriously I suppose. Such disappointment. Mark --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] NEW hdsp 9652 problems - {WAS: alsaconf -L - where's Waldo?)
Well, I guess thanks then for saving the rest of my vacation Friday from being a total waste of time. I took the day off to focus on getting this Alsa stuff going. Now I find I cannot. Too bad for me I guess. mark - i'm not trying to apportion blame, but i would note that if you had not updated the firmware, this would not have happened. also, i had hoped that takashi or jaroslav would have applied the patches already mailed to the mailing list to CVS, but they chose not for various reasons. i use my H-DSP almost every day, and it works without problems for most things (you know most of the issues). the problems you have had are unfortunate, and i regret them, but unfortunately i do not have write access to ALSA CVS (i'm not sure i want it), and trying to support the very confusing situation that RME have created with the H-DSP has been hard to do (2 PCI rev numbers, 2 incompatible ROM-based firmware versions, 2 versions of the driver-loaded firmware, plus the hdsp-9652 which is a lot like the h-dsp but has no driver-loaded firmware and different register access rules sigh). i believe that my work and now thomas's will be available very soon, and will make the hdsp a truly phenomenal card under linux. thomas also has written an almost-finished version of totalmix for linux (with bitmaps from RME), and that is really impressive to see running. next time you go to upgrade the firmware on anything (your BIOS, a SCSI adapter, a sound card), its best to be sure to ask first if it will affect existing driver's ability to interact with the h/w. --p --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] RE: Unitor8/AMT8 driver for alsa 0.9.0rc1
[...] It appeared that Martijn Sipkema was working on a library: http://sourceforge.net/mailarchive/message.php?msg_id=1511505 I'm sorry to say that it is nowhere near finished. --ms --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] NEW hdsp 9652 problems - {WAS: alsaconf -L -where's Waldo?)
On Fri, 2003-03-21 at 11:05, Paul Davis wrote: Well, I guess thanks then for saving the rest of my vacation Friday from being a total waste of time. I took the day off to focus on getting this Alsa stuff going. Now I find I cannot. Too bad for me I guess. mark - i'm not trying to apportion blame, but i would note that if you had not updated the firmware, this would not have happened. also, i had hoped that takashi or jaroslav would have applied the patches already mailed to the mailing list to CVS, but they chose not for various reasons. Paul, I completely accept responsibility for this series of problems. Between September and December I had an opportunity to choose what hardware to buy. I made my choice, right or wrong. From December until today I have waited for this hardware to really work, but it doesn't work today. Two weeks ago, wanting to compare Linux and Windows in more depth, and making no real progress with Linux, I pressed the button and allowed RME's software to update my card so that I could use the best they have to offer in Windows. It killed Linux. That was my choice, wise or not. On the positive side, I must tell people that Linux kicks but. I can run my box with Linux/Alsa/Jack, doing recording, or playing CDs, at sub 3mS latencies. I've pushed it down to 1.2mS and it's not failed, but I think it might. The same box, running Win XP, cannot do better than 12mS and seems to work better at 23mS. Guess which one I'd rather be using when I use soft synths live? This issue is not your fault, nor your responsility to fix. You are quite busy with two very important projects, Jack and Ardour. You don't need to become a focal point for developing specifc drivers. I don't expect it of you. I have come to understand just how much Alsa support is on a very adhoc basis. It is not possible, I think, for any user like myself to depend on a specific piece of hardware having support, or really knowing when any piece of hardware will _ever_ be supported. I've also come to find out just how much Alsa and Jack are still at the point of changing protocols. This causes things to break. Beyond that, there is a general sense that if developers want to change things and cause stuff to break, then users should just put up with it, or learn to compile kernels, or spend their time reading web sites to find solutions for problems that didn't exist the day before. I don't think that works very well, but I have no power to influence the outcome of you or anyone else in the development community when you press your buttons. The unfortunate part of this adventure into Linuxland is that 6 months has gone by and I have barely written music. This is not what I want, nor the way I'm willing to spend my time. Will this machine ever work in the future? I don't know, but I hope so. In the meantime I have a shiny new Athlon XP 2600+, 512MB of PC2700 DRAM, RME HDSP 9652 and a disk drive that's doing 45-50MB/Sec sitting here doing nothing but fetchmail. Cheers, Mark i use my H-DSP almost every day, and it works without problems for most things (you know most of the issues). the problems you have had are unfortunate, and i regret them, but unfortunately i do not have write access to ALSA CVS (i'm not sure i want it), and trying to support the very confusing situation that RME have created with the H-DSP has been hard to do (2 PCI rev numbers, 2 incompatible ROM-based firmware versions, 2 versions of the driver-loaded firmware, plus the hdsp-9652 which is a lot like the h-dsp but has no driver-loaded firmware and different register access rules sigh). i believe that my work and now thomas's will be available very soon, and will make the hdsp a truly phenomenal card under linux. thomas also has written an almost-finished version of totalmix for linux (with bitmaps from RME), and that is really impressive to see running. next time you go to upgrade the firmware on anything (your BIOS, a SCSI adapter, a sound card), its best to be sure to ask first if it will affect existing driver's ability to interact with the h/w. --p --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Need for a new ALSA developer?
well, I would like if you update the adatpci driver. or maybe the tascam428 driver :) On Fri, 2003-03-21 at 11:50, Robert Vetter wrote: Hello everybody, My name is Robert and I'm very much interested in working on ALSA Project with you. I primarily would like to develop a new driver for a souncard, which is not supported by ALSA yet, perhaps some USB stuff from Midiman? Please let me know what are the possibilities for me to be involved. Thanks Robert Vetter --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel -- My cat's a debugger Potter, Lorn, ljp core developer / Web Administrator Project OPIE- the Open Palmtop Integrated Environment http://opie.handhelds.org | http://www.opie.info (german) | http://www.opie.us IRC: irc.freenode.net #opie #opie.de [EMAIL PROTECTED] [EMAIL PROTECTED] --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [Alsa-user] Sound Card compatibility?
- Original Message - From: Luke Yelavich [EMAIL PROTECTED] To: Pete Barnard [EMAIL PROTECTED] Sent: Friday, March 21, 2003 1:18 PM Subject: Re: [Alsa-user] Sound Card compatibility? Hi That card will be fine, as it uses the snd-intel8x0 module. You shuldn't have any problems. Luke. Thanks for your reply. I have actualy been attempting to use it as a snd-intel8x0 model today, as you and others said. I have sucessfully installed the drivers/libraries etc and loaded the modules. But when I brought up the alsamixer there were controls missing (notably the ADC and DAC controls). My ALSA sound capture program (which successfully works on another machine using a cs46xx card) ran but only produced 0's and I was unable to get any output by playing with alsamixer. On my old machine (cs46xx card) I simply set the ADC and Capture flag and lifted up some gains but I cannot get alsamixer to make my program capture sound on the new machine as there is no ADC control - which means I cannot set that flag. Frustrating ! Here's a summary of what I have done so far. [EMAIL PROTECTED] root]# lspci 00:00.0 Host bridge: Intel Corp.: Unknown device 2560 (rev 01) 00:02.0 VGA compatible controller: Intel Corp.: Unknown device 2562 (rev 01) 00:1d.0 USB Controller: Intel Corp.: Unknown device 24c2 (rev 01) 00:1d.1 USB Controller: Intel Corp.: Unknown device 24c4 (rev 01) 00:1d.7 USB Controller: Intel Corp.: Unknown device 24cd (rev 01) 00:1e.0 PCI bridge: Intel Corp. 82801BA/CA PCI Bridge (rev 81) 00:1f.0 ISA bridge: Intel Corp.: Unknown device 24c0 (rev 01) 00:1f.1 IDE interface: Intel Corp.: Unknown device 24cb (rev 01) 00:1f.5 Multimedia audio controller: Intel Corp.: Unknown device 24c5 (rev 01) 05:08.0 Ethernet controller: Intel Corp.: Unknown device 103b (rev 81) *** /etc/module.conf ** alias parport_lowlevel parport_pc alias eth0 e100 alias usb-controller usb-uhci alias usb-controller1 ehci-hcd alias char-major-116 snd alias char-major-14 soundcore alias sound-slot-0 snd-card-0 alias sound-service-0-0 snd-mixers-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 alias snd-card-0 snd-card-intel8x0 post-install sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -L /dev/null 21 || : pre-remove sound-slot-0 /bin/aumix-minimal -f /etc/.aumixrc -S /dev/null 21 || : alias char-major-89 i2c-dev options it87 temp_type=0x31 * from alsa-drivers directory ./configure --with-cards=intel8x0 --with-sequencer=yes; make; make install; ./snddevices (all seems to go through with no errors) and then ./configure;make;make install for other alsa directories. ** modprobe snd-intel8x0; modprobe snd-pcm-oss; modprobe snd-mixer-oss modprobe snd (all had no errors) *** alsamixer (comes up ok but no ADC or DAC controls). My sound capture program runs but produces no output. Any help appreciated. Regards, Pete --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] midi problems with Quattro usb interface
Hi gurus, I'm seeing this weird problem in current cvs (same problem when tested with cvs of 20030307): Connections: Oxygen8 Midi output - Quattro Midi input Quattro USB - laptop USB port - start computer (with everything connected) a) usb system is loaded..., Quattro recognized, snd-usb-audio started b) alsasound loads the rest of the modules -- midi input does not work (tested with pd) This is the only way I have found to make it work (after MANY tries): - stop alsa driver (/etc/rc.d/init.d/alsasound stop) - disconnect Quattro from the usb port - disconnect Oxygen8 from the Quattro - this is what makes a difference - connect Quattro to the usb port (wait till it is recognized) - start alsa driver -- midi input works! Apparently having active sensing midi bytes coming in to the Quattro while the driver is being loaded kills input. I was not able to make things work if the keyboard is connected to the interface when alsa starts. A MidiSport2x2 works fine under the same conditions (using the open source firmware). It is not affected by the same Oxygen8 keyboard being plugged in when the driver starts. -- Fernando --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] BUG REPORT: Missing #include statements
Several C source files does not explicitly include the headers files they need; instead they rely on asoundlib.h to include them. Here is a list of missing includes: alsa-tools-0.9.0rc7/ac3dec/output.c: # include assert.h alsa-tools-0.9.0rc7/ac3dec/output.c: # include alloca.h alsa-tools-0.9.0rc7/ac3dec/output.c: # include string.h alsa-tools-0.9.0rc7/ac3dec/output.c: # include unistd.h alsa-tools-0.9.0rc7/envy24control/driverevents.c: # include assert.h alsa-tools-0.9.0rc7/envy24control/envy24control.c: # include assert.h alsa-tools-0.9.0rc7/envy24control/hardware.c: # include assert.h alsa-tools-0.9.0rc7/envy24control/mixer.c: # include assert.h alsa-tools-0.9.0rc7/envy24control/patchbay.c: # include assert.h alsa-tools-0.9.0rc7/envy24control/volume.c:# include assert.h alsa-tools-0.9.0rc7/sb16_csp/cspctl.c: # include fcntl.h alsa-tools-0.9.0rc7/sb16_csp/cspctl.c: # include unistd.h alsa-tools-0.9.0rc7/sb16_csp/cspctl.c: # include assert.h alsa-tools-0.9.0rc7/sb16_csp/cspctl.c: # include string.h alsa-tools-0.9.0rc7/sb16_csp/cspctl.c: # include errno.h alsa-tools-0.9.0rc7/seq/sbiload/sbiload.c: # include assert.h alsa-tools-0.9.0rc7/seq/sbiload/sbiload.c: # include unistd.h alsa-tools-0.9.0rc7/seq/sbiload/sbiload.c: # include fcntl.h alsa-utils-0.9.0rc7/seq/aseqnet/aseqnet.c: # include assert.h alsa-utils-0.9.0rc7/seq/aseqnet/aseqnet.c: # include errno.h This is not a problem for users of the standard asoundlib.h, but a problem when developing an alternative header file for a new language binding. As I do not have CVS access, I cannot update the source. Regards /Lars --- Lars Hamrén Tel...: +46(46)189090 Svensk Datorutveckling e-post: [EMAIL PROTECTED] Vadmöllan 211WWW...: www.sdu.se S-225 94 Lund Sweden --- This SF.net email is sponsored by: Tablet PC. Does your code think in ink? You could win a Tablet PC. Get a free Tablet PC hat just for playing. What are you waiting for? http://ads.sourceforge.net/cgi-bin/redirect.pl?micr5043en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] libao alsa playback
Hi, i've been debugging a problem with a xiph.org library called libao. Playing was distorted when using alsa but fine with oss. I tracked this down to libao using snd_pcm_hw_params_set_period_size instead of snd_pcm_hw_params_set_buffer_size. Changing to the later fixes the problem and playback is no longer distorted. All is well. But, i'd really like to understand what was going on and why the change fixed things. Anyone care to enlighten me? Thanks j. --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [Alsa-user] vxpocket / alsa 0.91/ recording freezes the system
At Mon, 17 Mar 2003 22:23:07 +, Matthew Yee-King wrote: i found it, too, and did a quick fix in the train returning from the LAD meeting last evening :) please try the cvs version. ok i've now got the cvs driver running. more observations: - recording doesn't crash the system now! - recordings are disorted when they come from the analog or digital input. (consumer spdif source) please update the cvs version again. i hope this problem is now fixed. Takashi --- This SF.net email is sponsored by:Crypto Challenge is now open! Get cracking and register here for some mind boggling fun and the chance of winning an Apple iPod: http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0031en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
