[Alsa-devel] Re: usx2y: known problems with us122 and alsa-drivers-1.0.1?
Am Samstag, 10. Januar 2004 20:27 schrieben Sie: Hi, I have built and installed ALSA 1.0.1 from tarballs for use with my new Tascam US-122. As far as I can tell, ALSA is correctly recognizing and loading firmware for this device. The USB light is on, the device shows up in /proc/asound as card # 0, etc. ALSA works properly on the internal card for this laptop, which is loaded as the second card, I can produce sound and so on. However, when I attempt to play a soundfile through the US-122 using aplay, it fails as follows. My question to you is: do you have any known problems with US-122 and alsa-1.0.1? no known problem for the US-428 here with a 2.4.23 kernel. Did not yet try any 2.6 kernel don't have an US-122. I did have to make a small change to alsa-kernel/usb/usbaudio.h in the tarball distro to add back some definitions for USB_DT_CS_* that are needed by the usb audio driver. Maybe this is evidence that the 1.0.1 distro is out of sync with authoritative source for usb-audio? Here is some possibly useful information about my system. Thanks in advance for any help you can provide. $ cat /proc/asound/version Advanced Linux Sound Architecture Driver Version 1.0.1. Compiled on Jan 10 2004 for kernel 2.6.0. $ cat /proc/asound/cards 0 [USX2Y ]: USB US-X2Y - TASCAM US-X2Y TASCAM US-X2Y (1604:8007 if 0 at 003/006) 1 [A5451 ]: ALI5451 - ALI 5451 ALI 5451 at 0x1000, irq 5 please give us the output of $ cat /proc/asound/devices! $ aplay -D hw:0 ~/gillian.wav Playing WAVE '/home/grib/gillian.wav' : Signed 16 bit Little Endian, Rate 44100 Hz, Stereo ALSA lib pcm_hw.c:324:(snd_pcm_hw_hw_params) SNDRV_PCM_IOCTL_HW_PARAMS failed: No such device aplay: set_params:875: Unable to install hw params: ACCESS: RW_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: 44100 PERIOD_TIME: (125011 125012) PERIOD_SIZE: 5513 PERIOD_BYTES: 22052 PERIODS: (2 3) BUFFER_TIME: (371519 371520) BUFFER_SIZE: 16384 BUFFER_BYTES: 65536 TICK_TIME: 1000 I have tried many normal variations of buffer sizes and so on but no change. Here is some other possibly useful information: OK, and it's in /dev also: $ ls -l /dev/snd total 0 crw-rw1 root audio116, 0 Dec 31 1969 controlC0 crw-rw1 root audio116, 32 Dec 31 1969 controlC1 crw-rw1 root audio116, 4 Dec 31 1969 hwC0D0 crw-rw1 root audio116, 8 Dec 31 1969 midiC0D0 crw-rw1 root audio116, 24 Dec 31 1969 pcmC0D0c crw-rw1 root audio116, 16 Dec 31 1969 pcmC0D0p crw-rw1 root audio116, 56 Dec 31 1969 pcmC1D0c crw-rw1 root audio116, 48 Dec 31 1969 pcmC1D0p crw-rw1 root audio116, 33 Dec 31 1969 timer When I attached the USB device, here's the message I saw in /var/log/messages: Jan 10 12:50:10 serrano kernel: hub 3-0:1.0: new USB device on port 2, assigned address 5 Jan 10 12:50:10 serrano kernel: midi: probe of 3-2:1.0 failed with error -5 Jan 10 12:50:11 serrano /etc/hotplug/usb/tascam_fw: load /usr/share/alsa/firmware/usx2yloader/us122fw.ihx for 1604/8006/100 to /proc/bus/usb/003/005 Jan 10 12:50:11 serrano kernel: usb 3-2: USB disconnect, address 5 Jan 10 12:50:13 serrano kernel: hub 3-0:1.0: new USB device on port 2, assigned address 6 Jan 10 12:50:13 serrano kernel: midi: probe of 3-2:1.0 failed with error -5 Jan 10 12:50:13 serrano /etc/hotplug/usb/tascam_fpga: calling /usr/bin/usx2yloader for /proc/bus/usb/003/006 Jan 10 12:50:15 serrano /etc/hotplug/usb/tascam_fpga: starting for /proc/bus/usb/003/006 Jan 10 12:50:15 serrano /etc/hotplug/usb/tascam_fpga: leaving --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: usx2y: known problems with us122 and alsa-drivers-1.0.1?
you might also try 2.6.1-mm1. ALSA 1.0.1 is integrated there, IIUC! regards, Karsten --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: usx2y: known problems with us122 and alsa-drivers-1.0.1?
On Sun, Jan 11, 2004 at 02:49:06PM +0100, Karsten Wiese wrote: Am Samstag, 10. Januar 2004 20:27 schrieben Sie: $ ls -l /dev/snd total 0 crw-rw1 root audio116, 0 Dec 31 1969 controlC0 crw-rw1 root audio116, 32 Dec 31 1969 controlC1 crw-rw1 root audio116, 4 Dec 31 1969 hwC0D0 crw-rw1 root audio116, 8 Dec 31 1969 midiC0D0 crw-rw1 root audio116, 24 Dec 31 1969 pcmC0D0c crw-rw1 root audio116, 16 Dec 31 1969 pcmC0D0p crw-rw1 root audio116, 56 Dec 31 1969 pcmC1D0c crw-rw1 root audio116, 48 Dec 31 1969 pcmC1D0p crw-rw1 root audio116, 33 Dec 31 1969 timer 1969 ? When I attached the USB device, here's the message I saw in /var/log/messages: Jan 10 12:50:10 serrano kernel: hub 3-0:1.0: new USB device on port 2, assigned address 5 Jan 10 12:50:10 serrano kernel: midi: probe of 3-2:1.0 failed with error -5 That's strange. Jan 10 12:50:11 serrano /etc/hotplug/usb/tascam_fw: load /usr/share/alsa/firmware/usx2yloader/us122fw.ihx for 1604/8006/100 to /proc/bus/usb/003/005 Jan 10 12:50:11 serrano kernel: usb 3-2: USB disconnect, address 5 Jan 10 12:50:13 serrano kernel: hub 3-0:1.0: new USB device on port 2, assigned address 6 Jan 10 12:50:13 serrano kernel: midi: probe of 3-2:1.0 failed with error -5 I don't see /dev/snd/seq. Can that be the cause? I've only 2.4 experience and there I use ./snddevices in alsa-driver for creating all the devices. crw-rw1 root audio116, 1 28. Mai 2003 seq And a fresh compiled alsa CVS runs fine with my us122. no problems and there are no midi changes at all. martin -- The only nice thing about spam is that it doesn't ring. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] [PATCH] ens1373/ct5880 - Switch Line In to Rear Out
Hi,
The Gigabyte GA-7DXR motherboard has a 4-channel SB128
(ct5880 + STAC9708/11) onboard. The line in and second line out (rear out)
are wired to the same connector.
After some trial-and-error with the ct5880 GPIO registers I found one which
switches line in to rear out.
The patch below adds a new mixer element when the ens1371 finds itself
on a GA-7DXR (by checking subsystem vendor device IDs).
Other motherboards with the ct5880 may have different IDs and/or
may require a different GPIO line.
Cheers,
Mike
--- alsa-driver-1.0.1-orig/alsa-kernel/pci/ens1370.c2003-10-28 12:28:01.0
+0100
+++ alsa-driver-1.0.1/alsa-kernel/pci/ens1370.c 2004-01-10 16:45:12.0 +0100
@@ -1512,6 +1512,54 @@
.put = snd_es1373_rear_put,
};
+static int snd_es1373_line_info(snd_kcontrol_t *kcontrol,
snd_ctl_elem_info_t *uinfo)
+{
+uinfo-type = SNDRV_CTL_ELEM_TYPE_BOOLEAN;
+uinfo-count = 1;
+uinfo-value.integer.min = 0;
+uinfo-value.integer.max = 1;
+return 0;
+}
+
+static int snd_es1373_line_get(snd_kcontrol_t * kcontrol,
snd_ctl_elem_value_t * ucontrol)
+{
+ ensoniq_t *ensoniq = snd_kcontrol_chip(kcontrol);
+ int val = 0;
+
+ spin_lock_irq(ensoniq-reg_lock);
+ if ((ensoniq-ctrl ES_1371_GPIO_OUTM) = 4)
+ val = 1;
+ ucontrol-value.integer.value[0] = val;
+ spin_unlock_irq(ensoniq-reg_lock);
+ return 0;
+}
+
+static int snd_es1373_line_put(snd_kcontrol_t * kcontrol,
snd_ctl_elem_value_t * ucontrol)
+{
+ ensoniq_t *ensoniq = snd_kcontrol_chip(kcontrol);
+ unsigned int nval1 = 0;
+
+ nval1 = ucontrol-value.integer.value[0];
+ spin_lock_irq(ensoniq-reg_lock);
+ if(nval1) {
+ ensoniq-ctrl |= ES_1371_GPIO_OUT(4); /* switch line-in - rear out */
+ } else {
+ ensoniq-ctrl = ~(ES_1371_GPIO_OUT(4));
+ }
+ outl(ensoniq-ctrl, ES_REG(ensoniq, CONTROL));
+ spin_unlock_irq(ensoniq-reg_lock);
+ return nval1;
+}
+
+static snd_kcontrol_new_t snd_ens1373_line __devinitdata =
+{
+ .iface =SNDRV_CTL_ELEM_IFACE_MIXER,
+ .name = Line In-Rear Out Switch,
+ .info = snd_es1373_line_info,
+ .get = snd_es1373_line_get,
+ .put = snd_es1373_line_put,
+};
+
static void snd_ensoniq_mixer_free_ac97(ac97_t *ac97)
{
ensoniq_t *ensoniq = snd_magic_cast(ensoniq_t,
ac97-private_data, return);
@@ -1586,6 +1634,11 @@
ensoniq-cssr |= ES_1373_REAR_BIT26;
snd_ctl_add(card, snd_ctl_new1(snd_ens1373_rear, ensoniq));
}
+ if ((ensoniq-subsystem_vendor_id == 0x1274)
+ (ensoniq-subsystem_device_id == 0x2000)) { /* GA-7DXR */
+snd_ctl_add(card, snd_ctl_new1(snd_ens1373_line, ensoniq));
+ }
+
return 0;
}
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Moving from OSS to ALSA
Hello,
I am currently looking into rewriting our current OSS sound routines to native
ALSA, as it seems OSS will invariably be phased out now that the ALSA driver is
distrubuted with the Linux kernel, plus ALSA seems to have a great number of benefits
for us.
Our current sound routines perform software sound sample mixing for use in games.
All the mixing and transfers happen in a non-blocking function called update_jsound()
which we call every 1/60th of a second in our main game loop. We find the total size
of the hardware ring buffer and use MMAP writes to it. We effectively break the ring
buffer into 1024 byte fragments, and always keep one whole fragment ahead to ensure
no underruns. We do this by the follwing:
ioctl(audiofd, SNDCTL_DSP_GETOPTR, info); // get position of DSP pointer
if (info.ptr = trigger){ // hit a frag boundary, so write another fragment ahead
trigger += FRAGSIZE; // move triggering position to next fragment boundary
if (trigger = DMA_SIZE) trigger = 0; // wrap around if at end of DMA buffer
dptr = DMA_PTR + trigger; // set write ptr to next fragment
...
mix and write all samples playing into the buffer
...
//printf(Ptr position: %u\n, info.ptr);
//printf(Trigger: %u\n, trigger);
}
With all the different methods available the ALSA offers i'm finding it hard to
determine the best method to use to do the same job as the OSS code. I have started by
writing a standard write access with non-blocking, with a buffersize of 50
usecs and a period time of 10 usecs, but i want to know how to determine if there
is only one period remaning, which is when i would want to mix and write the next one
ahead...
Sorry if this has been covered before...
Thanks,
James
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Moving from OSS to ALSA
I am currently looking into rewriting our current OSS sound routines to nat ive ALSA, as it seems OSS will invariably be phased out now that the ALSA driv er is distrubuted with the Linux kernel, plus ALSA seems to have a great numbe r of benefits for us. Our current sound routines perform software sound sample mixing for use in g ames. All the mixing and transfers happen in a non-blocking function called u pdate_jsound() which we call every 1/60th of a second in our main game loop. W e find the total size of the hardware ring buffer and use MMAP writes to it. W e effectively break the ring buffer into 1024 byte fragments, and always kee p one whole fragment ahead to ensure no underruns. We do this by the follwing: best method: --- 1) set the avail_min s/w parameter to the period size 2) call poll on the file descriptor(s) returned from snd_pcm_poll_descriptors(). when you return from poll, you know you have at least one period of data ready (possibly more, so you need to check). 3) use snd_pcm_mmap_*() to handle mmap access. ALSA doesn't provide simple access to mmap'ped buffers because this could not work for some classes of ALSA devices. survey the source of JACK (jackit.sf.net) for some ideas. however, that probably won't work so well for you it doesn't integrate into your game loop. for that, use snd_pcm_delay() to find out the gap between the application (s/w) pointer and the hardware pointer, then use the snd_pcm_mmap_*() calls from there. its a lot more complex under ALSA. but thats because ALSA provides a lot of things that OSS does not, and doing everything via the simple system call interface that OSS uses makes it impossible to provide them appropriately. if you were writing software for musicians and studios rather than games and consumer media apps, check out JACK for a different, simpler and more powerful API (that uses ALSA internally). --p --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Moving from OSS to ALSA
Ultimately i think with ALSA we could do away with the concept of calling
update_jsound() in the game loop and instead use asyncrosnous mode and use
update_jsound() as my callback function? Although i'd need to get ALSA to call
update_jsound() when we are in our last period, so we can write another one ahead...
any ideas?
In the meantime can i not use snd_pcm_avail_update() to determine if we need to
write a period ahead?;
avail = snd_pcm_avail_update(pcm_handle);
if (avail = (buffer_size - period_size)){
mix_sound(MIXBUFFER, period_size); // mix a period wirth of channels
ret = snd_pcm_writen(pcm_handle, (void *) MIXBUFFER, period_size); // write it
}
Many Thanks,
James
On Sun, 11 Jan 2004 13:28:57 -0500
Paul Davis [EMAIL PROTECTED] wrote:
I am currently looking into rewriting our current OSS sound routines to nat
ive ALSA, as it seems OSS will invariably be phased out now that the ALSA driv
er is distrubuted with the Linux kernel, plus ALSA seems to have a great numbe
r of benefits for us.
Our current sound routines perform software sound sample mixing for use in g
ames. All the mixing and transfers happen in a non-blocking function called u
pdate_jsound() which we call every 1/60th of a second in our main game loop. W
e find the total size of the hardware ring buffer and use MMAP writes to it. W
e effectively break the ring buffer into 1024 byte fragments, and always kee
p one whole fragment ahead to ensure no underruns. We do this by the follwing:
best method:
---
1) set the avail_min s/w parameter to the period size
2) call poll on the file descriptor(s) returned from
snd_pcm_poll_descriptors(). when you return from poll,
you know you have at least one period of data ready (possibly
more, so you need to check).
3) use snd_pcm_mmap_*() to handle mmap access. ALSA
doesn't provide simple access to mmap'ped buffers
because this could not work for some classes of
ALSA devices.
survey the source of JACK (jackit.sf.net) for some ideas.
however, that probably won't work so well for you it doesn't integrate
into your game loop. for that, use snd_pcm_delay() to find out the
gap between the application (s/w) pointer and the hardware pointer,
then use the snd_pcm_mmap_*() calls from there.
its a lot more complex under ALSA. but thats because ALSA provides a
lot of things that OSS does not, and doing everything via the simple
system call interface that OSS uses makes it impossible to provide
them appropriately.
if you were writing software for musicians and studios rather than
games and consumer media apps, check out JACK for a different, simpler
and more powerful API (that uses ALSA internally).
--p
---
This SF.net email is sponsored by: Perforce Software.
Perforce is the Fast Software Configuration Management System offering
advanced branching capabilities and atomic changes on 50+ platforms.
Free Eval! http://www.perforce.com/perforce/loadprog.html
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] [REPORT as said in via82xx.c] ad1980 Asus A7V8X-X Working
I'm use via82xx module for ad1980 Asus A7V8X-X with option dxs_support=1 and weird sounds gets out, master channel volume seems to be Surround, and VIA DXS (first one) needs to be at 75% to hear full volume, other positions doesn't work. PCM sound from whatever is a little bit weird because conversion to 48k, but just fine, if we use arts, we can set sampling to 48k and everything is perfect. I will try to modify, by my self surround by master channel from via82xx.c, but when I finish the read of documentation of api (I'm newbe) Best regards. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Moving from OSS to ALSA
On Monday 12 January 2004 4:13 am, James Wright wrote: I am currently looking into rewriting our current OSS sound routines to native ALSA, as it seems OSS will invariably be phased out now that the ALSA driver is distrubuted with the Linux kernel, plus ALSA seems to have a great number of benefits for us. Personally, I hope OSS compat will never be phased out. Why? OSS is simple, and concise. If I am writing a simple audio recording/playing app, I can get the job done using OSS code in _much_ less lines of code. _Dont get me wrong_, ALSA is great and a lot more powerful than OSS, but it is lacking a simple API. Ever try to write an In/Out volume control mixer in OSS? Ever try to port that same mixer to ALSA? From what I can gather (alsa seems to be lacking mixer docs/tutorial) , the only way to change the mic input level (alsa), I have to enumerate over every mixer gizmo and check to see if its the mic, and then change it if I think it appears to be the Mic. Using OSS, I can do that in one line. --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: Moving from OSS to ALSA
Lorn Potter [EMAIL PROTECTED] writes: On Monday 12 January 2004 4:13 am, James Wright wrote: I am currently looking into rewriting our current OSS sound routines to native ALSA, as it seems OSS will invariably be phased out now that the ALSA driver is distrubuted with the Linux kernel, plus ALSA seems to have a great number of benefits for us. Personally, I hope OSS compat will never be phased out. Why? OSS is simple, and concise. If I am writing a simple audio recording/playing app, I can get the job done using OSS code in _much_ less lines of code. I have to disagree. For my music/video player, I've written both ALSA and OSS output modules. The ALSA module is 261 lines, the OSS module 258 lines, including comments and whitespace. The ALSA module does things that are more or less impossible with OSS, such as sample accurate timing. -- Måns Rullgård [EMAIL PROTECTED] --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Moving from OSS to ALSA
On Mon, 12 Jan 2004 08:29:54 +1000 Lorn Potter [EMAIL PROTECTED] wrote: On Monday 12 January 2004 4:13 am, James Wright wrote: I am currently looking into rewriting our current OSS sound routines to native ALSA, as it seems OSS will invariably be phased out now that the ALSA driver is distrubuted with the Linux kernel, plus ALSA seems to have a great number of benefits for us. Personally, I hope OSS compat will never be phased out. Why? OSS is simple, and concise. If I am writing a simple audio recording/playing app, I can get the job done using OSS code in _much_ less lines of code. This is true, but for our application (games) we need very low latency, and hence fast mixing and writes. It now seems pointless using our OSS code if its then going to be emulated by ALSA. I'm sure if i stick with ALSA i can get real nice results, its just a steep learning curve for ALSA n00bs like me... :( If I was writing a basic audio app with little consideration for latency and efficiency i'd probably have stuck with OSS and ALSA emulation... The main feature i'm interested in is the asychronous pcm playback, it means we can setup the sounds mixer, and not have to worry about calling an update_sound() function every 1/20th of a sec... _Dont get me wrong_, ALSA is great and a lot more powerful than OSS, but it is lacking a simple API. Ever try to write an In/Out volume control mixer in OSS? Ever try to port that same mixer to ALSA? From what I can gather (alsa seems to be lacking mixer docs/tutorial) , the only way to change the mic input level (alsa), I have to enumerate over every mixer gizmo and check to see if its the mic, and then change it if I think it appears to be the Mic. Using OSS, I can do that in one line. I haven't looked at porting our /dev/mixer routines yet, sounds like its going to be fun! --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Moving from OSS to ALSA
On Mon, 12 Jan 2004, Lorn Potter wrote: I am currently looking into rewriting our current OSS sound routines to native ALSA, as it seems OSS will invariably be phased out now that the ALSA driver is distrubuted with the Linux kernel, plus ALSA seems to have a Personally, I hope OSS compat will never be phased out. Why? OSS is simple, and concise. If I am writing a simple audio recording/playing app, I can get the job done using OSS code in _much_ less lines of code. Excuse me!? A major problem of OSS/kernel is that it is _not_ concise. Different OSS drivers implement the OSS API slightly differently (full-duplex, triggering, mmap support). This is a huge pain for the app developers as you have to verify your app against n+1 different drivers. With ALSA, when you write an application that works with one card, it is very likely that it will work perfectly on all the others too. This is made possible by the common alsa-kernel middle layer that is shared by all drivers. With OSS, there are n+1 implementations in the kernel of this middle level functionality. Now the commercial OSS (www.opensound.com) is a different thing. It too (like ALSA) provides coherent behaviour across different drivers. _Dont get me wrong_, ALSA is great and a lot more powerful than OSS, but it is lacking a simple API. Ever try to write an In/Out volume control mixer in OSS? Ever try to port that same mixer to ALSA? Believe me, I agree with you 100% with regards to importance of simplicity. ALSA still has some complex edges, but is has come a long way. More documentation, tutorials and example code are still needed, but it takes time (and volunteers) to create them. I'm sure help is appreciated. From what I can gather (alsa seems to be lacking mixer docs/tutorial) , the only way to change the mic input level (alsa), I have to enumerate over every mixer gizmo and check to see if its the mic, and then change it if I think it appears to be the Mic. [...] Using OSS, I can do that in one line. But that's just one example. ALSA needs to support much more complex mixer configurations than OSS, and this of course comes with a price. It is very difficult to try to hide all this complexity from the developer without in the end limiting what the developer can do. So it's a question of finding out a good balance between what can be done and how easy it is. I guess currently ALSA is still too much on the complex side, but slowly the correct balance will be found... So your input is very much appreciated, but at the same time, please don't lose hope just yet. :) -- http://www.eca.cx Audio software for Linux! --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Moving from OSS to ALSA
On Monday 12 January 2004 9:11 am, Kai Vehmanen wrote: Now the commercial OSS (www.opensound.com) is a different thing. It too (like ALSA) provides coherent behaviour across different drivers. I guess this is what I am talking about, really. _Dont get me wrong_, ALSA is great and a lot more powerful than OSS, but it is lacking a simple API. Ever try to write an In/Out volume control mixer in OSS? Ever try to port that same mixer to ALSA? Believe me, I agree with you 100% with regards to importance of simplicity. ALSA still has some complex edges, but is has come a long way. More documentation, tutorials and example code are still needed, but it takes time (and volunteers) to create them. I'm sure help is appreciated. The problem here is, the people writing docs/tutorials need in depth knowledge of how this all works. And unfortunately, the best people to do this are the developers themselves. But that's just one example. ALSA needs to support much more complex mixer configurations than OSS, and this of course comes with a price. It is very difficult to try to hide all this complexity from the developer without in the end limiting what the developer can do. So it's a question of finding out a good balance between what can be done and how easy it is. I guess currently ALSA is still too much on the complex side, but slowly the correct balance will be found... So your input is very much appreciated, but at the same time, please don't lose hope just yet. :) Oh, I havent lost hope at all. I am very excited about ALSA nearing version 1. I don't want to limit what alsa can do, only have access to a simple-ized part of the API, that's fast and easy for developers to write. Which is what I view the OSS compat. to be. I work with embedded devices, and so I am always thinking of ways to optimize the code and make apps smaller, which also means writing more app with less code. -- http://www.eca.cx Audio software for Linux! -- Lorn 'ljp' Potter Qtopia Community Manager lpotter at trolltech.com --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Patch to fix Pax/Grsecurity Problems
As you may be currently aware alsa-lib (libasound) does not work very well when using
it under a kernel that has the Pax (http://pax.grsecurity.net) or Grsecurity
(http://www.grsecurity.net) Patch.
The problem is because there is a function in a function (trampoline) - So gcc
generates code that conflicts with pax. Also there is a text-relocation problem.
So I helped create patch that will fix these problems so alsa will be more usable on a
Pax/Grsecurity machine (no chpax work arounds and more security). Currently this
patch is included in alsa-lib-1.0.1 in Gentoo so it is undergoing large scale testing.
For my part I have 2 machines running with Pax and this alsa-lib patch and I have had
no problems :)
The code is a work around so if you know of a better way to do it please tell me.
Get advanced SPAM filtering on Webmail or POP Mail ... Get Lycos Mail!
http://login.mail.lycos.com/r/referral?aid=27005diff -Nru alsa-lib-1.0.0rc2-original/src/control/hcontrol.c
alsa-lib-1.0.0rc2/src/control/hcontrol.c
--- alsa-lib-1.0.0rc2-original/src/control/hcontrol.c Mon Oct 13 08:06:46 2003
+++ alsa-lib-1.0.0rc2/src/control/hcontrol.cSat Dec 20 13:48:32 2003
@@ -48,6 +48,7 @@
#include string.h
#include fcntl.h
#include sys/ioctl.h
+#include pthread.h
#ifndef DOC_HIDDEN
#define __USE_GNU
#endif
@@ -409,17 +410,26 @@
return 0;
}
+static snd_hctl_t *compare_hctl;
+static int hctl_compare(const void *a, const void *b) {
+ return compare_hctl-compare(*(const snd_hctl_elem_t * const *) a,
+*(const snd_hctl_elem_t * const *) b);
+}
+
static void snd_hctl_sort(snd_hctl_t *hctl)
{
unsigned int k;
- int compar(const void *a, const void *b) {
- return hctl-compare(*(const snd_hctl_elem_t * const *) a,
-*(const snd_hctl_elem_t * const *) b);
- }
+ static pthread_mutex_t sync_lock = PTHREAD_MUTEX_INITIALIZER;
+
assert(hctl);
assert(hctl-compare);
INIT_LIST_HEAD(hctl-elems);
- qsort(hctl-pelems, hctl-count, sizeof(*hctl-pelems), compar);
+
+ pthread_mutex_lock(sync_lock);
+ compare_hctl = hctl;
+ qsort(hctl-pelems, hctl-count, sizeof(*hctl-pelems), hctl_compare);
+ pthread_mutex_unlock(sync_lock);
+
for (k = 0; k hctl-count; k++)
list_add_tail(hctl-pelems[k]-list, hctl-elems);
}
diff -Nru alsa-lib-1.0.0rc2-original/src/pcm/pcm_direct.c
alsa-lib-1.0.0rc2/src/pcm/pcm_direct.c
--- alsa-lib-1.0.0rc2-original/src/pcm/pcm_direct.c Fri Oct 17 09:53:06 2003
+++ alsa-lib-1.0.0rc2/src/pcm/pcm_direct.c Sat Dec 20 13:49:22 2003
@@ -98,7 +98,6 @@
int snd_pcm_direct_shm_create_or_connect(snd_pcm_direct_t *dmix)
{
- static int snd_pcm_direct_shm_discard(snd_pcm_direct_t *dmix);
struct shmid_ds buf;
int ret = 0;
[Alsa-devel] RE: [ACPI] can't switch CPU frequency while running on batterypower
Did you find any warning or error message in boot log? Maybe there are some potential ACPI bug. I get the cpufreq warning here: ACPI: Processor [CPU0] (supports C1 C2, 8 throttling states) ACPI: Thermal Zone [ATF0] (24 C) ACPI: No IRQ known for interrupt pin A of device :00:1f.1 - using IRQ 255 cpufreq: No CPUs supporting ACPI performance management found. DIsabling acpi performance managament doesn't change the /proc/acpi/processor/CPU0/limit output. greetings, Defiant --- This SF.net email is sponsored by: Perforce Software. Perforce is the Fast Software Configuration Management System offering advanced branching capabilities and atomic changes on 50+ platforms. Free Eval! http://www.perforce.com/perforce/loadprog.html ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
