[Alsa-devel] Re: [Alsa-user] sb live dma buffer alloc failure?
At Wed, 12 Feb 2003 18:00:29 -0500, Brian J. Tarricone [EMAIL PROTECTED] wrote: just a quick update - i installed yesterday's cvs of alsa-driver, and i haven't had any problems (no alloc failures or apps locking up) since then. i've tried to stress test it a bit (filling up ram, opening and closing the pcm device rapidly), and i'm pleased to say no problems. i looked at the cvs logs, quite a bit has been done in sg_buf.c since rc7, perhaps something there had an impact? even if this is just a side-effect of other work, thanks for the fix, guys ^_^ thanks for your report. in the cvs version, sg-buffer handler pre-allocates the buffer and keep it as other buffer types, so that the buffer re-allocation wouldn't happen rarely. so, it's not a side effect :) ciao, 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] [PATCH]: Bug: ALSA Sequencer or MTPAV - easy to reproduce
Hi, At Wed, 12 Feb 2003 14:35:29 -0800, Ryan Pavlik wrote: On Wed, 12 Feb 2003 21:41:50 +0100 (CET) Jaroslav Kysela [EMAIL PROTECTED] wrote: snip It seems that mtpav don't remeber the old status byte for each channels. If it's true, then we need to take care about the expansion in the mtpav driver, because the sequencer MIDI driver removes duplicated status bytes to opmitize throughput. snip OK, I've attached a patch that emulated running status in the mtpav driver, so there shouldn't be any need to change stuff elsewhere. Thanks for your pointer, I've been wanting to fix this problem for a very long time. :-) thanks for the patch. i applied it to cvs with a little improvement (returning immediately if snd_rawmidi_transmit() gets null). also, i found a bug regarding magic-alloc/free in the driver (at last!). fixed on cvs, too. ciao, 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] RME installation problems
At Wed, 12 Feb 2003 21:07:40 +0100, Orm Finnendahl wrote: Hi Justin, all, Am Mittwoch, den 12. Februar 2003 um 19:30:00 Uhr (+) schrieb Justin Cormack: ie add the 0xb revision. that did the trick. Seems to work fine now. I can't check all the way, as I'm in Berlin and the Computer is at V2 in Rotterdam without someone there being able to connect to sound out, but Alsamixer shows up correctly. Thanks a lot! Someone should commit that to cvs. i don't see the mails on ML, so not 100% sure how to fix (although i guess above mentioned to add the new revision in the check in snd_rme9652_create()...) could you send a patch? thanks, 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] intel8x0 driver motorboots (gets caught in loop) in Quake 3
At Wed, 12 Feb 2003 18:54:01 +0100, Josh Buhl wrote: When running Quake 3 Arena the sound initializes properly and plays correctly during the game until the end of a match. At this point, the game abruptly enters a different mode (this is where the models of the players for the first, second, and third placements are shown on pedestals and a voice says Grunt Wins! or whatever) and the game locks up with a small segment of sound being repeated in a loop. could you check whether the interrupts properly generated during the repeated sounds? 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] playing underruns
Hi, check LAD site, http://www.linuxdj.com/audio/lad/resourceslatency.php3 you'll find some good information how to get low-latency. Takashi At Wed, 12 Feb 2003 17:56:19 -0500, Chris Raphael wrote: Hello List, This is my first post and I am new (a couple of weeks) to ALSA. I am working on an application that plays audio output in response to audio input --- the relationship between input and output is complicated and I will not describe it in any detail here --- I am building a musical accompaniment system. I want the output to respond to the input with low latency so I cannot write the output samples very long before they are actually going to be played. Currently I have a function that is called repeatedly (through a signal) and writes the samples about .05 secs before they will actually be played. I monitor the delay, in samples, (I can't remember the name of the function (snd_delay_???) and see that the number of unplayed samples fluctuates but there does not seem to be an increasing or decreasing trend. So I assume that I am writing at very close to the right rate and mostly the playback sounds fine. But every so often, maybe once every 10 secs or so, I get a playback underrun. I always check the system clock when my writing routine begins, so I know the underruns are almost always *not* due to my writing routine getting a late callback. By everything I can measure, the samples are written on time. Can anyone tell me what I need to do to fix this problem? Perhaps it is not reasonable of me to hope to write samples such a short time before they need to be played? I would really appreciate any help I can get on this and will supply any relevant details. I just didn't want to clutter up my question with lots of irrelevant info. Thanks, Christopher Raphael --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- This sf.net email is sponsored by:ThinkGeek Welcome to geek heaven. http://thinkgeek.com/sf ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] intel8x0 driver motorboots (gets caught in loop)in Quake 3
Hi Takashi, could you check whether the interrupts properly generated during the repeated sounds? I'll be happy to do whatever I can, but I don't exactly know what you mean. How do I check whether the interrupts are properly generated? I'm fairly certain that I don't have any irq conflicts: josh@spleen:/var/tmp/blah$ cat /proc/interrupts CPU0 0: 860465 XT-PIC timer 1: 11671 XT-PIC keyboard 2: 0 XT-PIC cascade 4: 52364 XT-PIC serial 5: 26156 XT-PIC eth1 8: 3 XT-PIC rtc 10: 44468 XT-PIC SiS SI7012 11: 657820 XT-PIC nvidia 12: 0 XT-PIC eth0 14: 36395 XT-PIC ide0 15: 84988 XT-PIC ide1 NMI: 0 ERR: 0 josh@spleen:/var/tmp/blah$ -josh -- When you wake up in the morning, Pooh, said Piglet at last, what's the first thing you say to yourself? What's for breakfast? said Pooh. What do you say, Piglet? I say, 'I wonder what's going to happen exciting today?' said Piglet. Pooh nodded thoughtfully. It's the same thing, he said. -- A.A. Milne - http://www.nyfairuse.org/ WTO + WIPO = DMCA http://www.anti-dmca.org Innovation vs Patent Inflation http://swpat.ffii.org/ 12 voices and 400 Firms against logic patents http://www.noepatents.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
[Alsa-devel] A simple question, Alsa on debian
A simple question, does the current Alsa release tarball work out of the box ?as is?, i.e. ./configure ;make install on Debian current release, compiled kernel 2.4.20. I am doing some work on the es18xx.c and don?t want to hit my head in the wall if there are any problems with respect to the package system that would hinder progress. (It seems to work but alas I want to make sure with you professionals.) By the way I think I am getting the hang of this now :-), It does take some knowledge in bit manipulation and knowing about the issues such as one read inb() equals 1 microsecond and not getting 0x-ed in your brain. Best regards from Erik _ Här börjar internet! Skaffa gratis e-mail och gratis internet på http://www.spray.se Träffa folk från hela Sverige på ett och samma ställe - http://chat.spray.se/
Re: [Alsa-devel] intel8x0 driver motorboots (gets caught in loop) in Quake 3
At Thu, 13 Feb 2003 11:08:03 +0100, Josh Buhl wrote: Hi Takashi, could you check whether the interrupts properly generated during the repeated sounds? I'll be happy to do whatever I can, but I don't exactly know what you mean. How do I check whether the interrupts are properly generated? check /proc/interrupts during the playback whether the number of irq 10 increases. also, check the status shown in /proc/asound/card0/pcm0p/sub0 during the playback, too. ciao, 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] RME installation problems
Hi Takashi, Am Donnerstag, den 13. Februar 2003 um 10:31:09 Uhr (+0100) schrieb Takashi Iwai: ie add the 0xb revision. i don't see the mails on ML, so not 100% sure how to fix (although i guess above mentioned to add the new revision in the check in snd_rme9652_create()...) Yes. In the old driver it just checks for 0xa and 0x64. Just add a line to also check for 0xb. could you send a patch? Not right now. The computer is in Rotterdam and I'm in Berlin. It crashed so I'm waiting for someone to arrive on location and restart it. I don't have any Alsa stuff here at the moment. Let me know if you still need it and I'll send it to you later. -- Orm --- 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] intel8x0 driver motorboots (gets caught in loop)in Quake 3
check /proc/interrupts during the playback whether the number of irq 10 increases. During the looped sound, the number of interrupts increases by about fifty a second: josh@spleen:/proc$ date; cat interrupts | grep SiS Thu Feb 13 11:41:10 CET 2003 10: 64806 XT-PIC SiS SI7012 josh@spleen:/proc$ date; cat interrupts | grep SiS Thu Feb 13 11:41:20 CET 2003 10: 65281 XT-PIC SiS SI7012 also, check the status shown in /proc/asound/card0/pcm0p/sub0 during the playback, too. Here are several polls taken a couple of seconds apart while the looped sound is playing: josh@spleen:/proc$ cat asound/card0/pcm0p/sub0/status state: RUNNING trigger_time: 1045132684.647330 tstamp : 1045133005.954117 delay : -11695398 avail : 11711782 avail_max : 11711782 - hw_ptr : 15423782 appl_ptr: 3728384 josh@spleen:/proc$ cat asound/card0/pcm0p/sub0/status state: RUNNING trigger_time: 1045132684.647330 tstamp : 1045133012.359933 delay : -12002901 avail : 12019285 avail_max : 12019285 - hw_ptr : 15731285 appl_ptr: 3728384 josh@spleen:/proc$ cat asound/card0/pcm0p/sub0/status state: RUNNING trigger_time: 1045132684.647330 tstamp : 1045133015.458098 delay : -12151624 avail : 12168008 avail_max : 12168008 - hw_ptr : 15880008 appl_ptr: 3728384 --- 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] emu10k1 bug and patch (0.9.0rc7)
Hi, I discovered a bug in the emu10k1 driver which I'll explain here:
I was developing an application which uses the timestamps given in the
status of the device to send S/PDIF data to it. This app worked pretty
well except that sometimes I heard sound discontinuities and then a
constant time delay between the sound and the video.
I finally found where was the problem, my results is based on the
emu10k1-debug.patch file attached. The frame argument is equal to 0
when the app gets the status of the device. With this patch applied I
saw some output on the console exactly at the same time the bug occured.
Adding a else after the if to prevent sw_ready from being updated
fixed the problem and the output looked like
plop 0 -1536 A B
plop 0 1536 B A
where B == A - 1536 (1536 is the period_size). These two lines were
repeated a few times during playback.
So the bug looks like a signedness problem since sw_ready is unsigned
and there is a while(sw_ready 0), which explain the constant delay,
next in the snd_emu10k1_fx8010_playback_transfer function.
So the emu10k1.patch file attached fixes the problem and seems not to
introduce new ones.
Note: patches were made with the 0.9.0rc7 version of the alsa-driver
package.
Regards,
--
Arnaud.
--- alsa-kernel/pci/emu10k1/emufx.c.orig2003-02-08 23:02:50.0 +0100
+++ alsa-kernel/pci/emu10k1/emufx.c 2003-02-08 23:17:09.0 +0100
@@ -531,6 +531,11 @@
if (diff) {
if (diff -(snd_pcm_sframes_t) (runtime-boundary / 2))
diff += runtime-boundary;
+ if(frames == 0)
+ {
+ printk(plop %d %ld (%lu %u)\n,
+ pcm-sw_ready, diff, appl_ptr, pcm-appl_ptr);
+ }
pcm-sw_ready += diff;
}
pcm-sw_ready += frames;
--- alsa-kernel/include/emu10k1.h.orig 2003-02-08 23:00:43.0 +0100
+++ alsa-kernel/include/emu10k1.h 2003-02-08 23:02:02.0 +0100
@@ -879,7 +879,8 @@
unsigned char etram[32];/* external TRAM address data */
unsigned int sw_data, hw_data;
unsigned int sw_io, hw_io;
- unsigned int sw_ready, hw_ready;
+ int sw_ready;
+ unsigned int hw_ready;
unsigned int appl_ptr;
unsigned int tram_pos;
unsigned int tram_shift;
Re: [Alsa-devel] RME installation problems
On Thu, Feb 13, 2003 at 11:44:24AM +0100, Orm Finnendahl wrote: Hi Takashi, Am Donnerstag, den 13. Februar 2003 um 10:31:09 Uhr (+0100) schrieb Takashi Iwai: ie add the 0xb revision. i don't see the mails on ML, so not 100% sure how to fix (although i guess above mentioned to add the new revision in the check in snd_rme9652_create()...) Yes. In the old driver it just checks for 0xa and 0x64. Just add a line to also check for 0xb. it's in hdsp, not rme9652! martin --- 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] RME installation problems
At Thu, 13 Feb 2003 12:08:51 +0100, Martin Langer wrote: On Thu, Feb 13, 2003 at 11:44:24AM +0100, Orm Finnendahl wrote: Hi Takashi, Am Donnerstag, den 13. Februar 2003 um 10:31:09 Uhr (+0100) schrieb Takashi Iwai: ie add the 0xb revision. i don't see the mails on ML, so not 100% sure how to fix (although i guess above mentioned to add the new revision in the check in snd_rme9652_create()...) Yes. In the old driver it just checks for 0xa and 0x64. Just add a line to also check for 0xb. it's in hdsp, not rme9652! yeah, slipped finger :) but i don't see any 0x64 there... anyway, check the attached patch. is it correct? Takashi hdsp-id-fix.dif Description: Binary data
[Alsa-devel] S/PDIF on AD1980 patch
Hi all, I recently installed an Asus P4PE with built in AD1980 audio codec (accessible through the ICH4 south bridge). The latest ALSA drivers detected the chip and AC97 audio correctly even setting up the IEC958 controls. The problem is I still got no output on the external S/PDIF module. I downloaded the specs from Analog Devices and found the register responsible for this, modified the AC97 codec drivers to add a control for the 3 flags specific to this chip (ie. outside of the ac97 specification) concerning the digital interface and managed to turn it on. I would like to submit this modification so that others who may have a similar setup can use it. So my question is : what's next? Who can merge such patches to the CVS tree and what is the validation and/or testing procedure? Or do I just mail the code to 'perex' and he takes care of it? I found similar patches for different chips with controls specific to them, so I assume this is the accepted solution, although it would also be possible simply initialize this register to the on value on startup - since this is a dedicated digital output, not shared with lfe/center like on Creative's sound cards. Jaroslaw Sobierski -- Fycio (J.Sobierski) [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] A simple question, Alsa on debian
I'm running alsa-0.9rc7 just fine on a slightly modified Debian 3.0r1 (I've upgraded a few packages to versions in sarge or sid) with kernel 2.4.20. I did not use the regular alsa tarball, but rather the alsa-source_0.9.0rc7-1_all.deb available in sid. I made it with make-kpkg --revision spleen.030205.1 modules_image After I installed the thus made alsa-modules-2.4.20_0.9.0rc7-1_i386.deb it did run out of the box. Does this help? -josh Erik Welander wrote: A simple question, does the current Alsa release tarball work out of the box ?as is?, i.e. ./configure ;make install on Debian current release, compiled kernel 2.4.20. I am doing some work on the es18xx.c and don?t want to hit my head in the wall if there are any problems with respect to the package system that would hinder progress. (It seems to work but alas I want to make sure with you professionals.) By the way I think I am getting the hang of this now :-), It does take some knowledge in bit manipulation and knowing about the issues such as one read inb() equals 1 microsecond and not getting 0x-ed in your brain. Best regards from Erik _ Här börjar internet! Skaffa gratis e-mail och gratis internet på http://www.spray.se Träffa folk från hela Sverige på ett och samma ställe - http://chat.spray.se/ -- When you wake up in the morning, Pooh, said Piglet at last, what's the first thing you say to yourself? What's for breakfast? said Pooh. What do you say, Piglet? I say, 'I wonder what's going to happen exciting today?' said Piglet. Pooh nodded thoughtfully. It's the same thing, he said. -- A.A. Milne - http://www.nyfairuse.org/ WTO + WIPO = DMCA http://www.anti-dmca.org Innovation vs Patent Inflation http://swpat.ffii.org/ 12 voices and 400 Firms against logic patents http://www.noepatents.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] S/PDIF on AD1980 patch
At Thu, 13 Feb 2003 03:19:02 -0800, Jaroslaw Sobierski wrote: Hi all, I recently installed an Asus P4PE with built in AD1980 audio codec (accessible through the ICH4 south bridge). The latest ALSA drivers detected the chip and AC97 audio correctly even setting up the IEC958 controls. The problem is I still got no output on the external S/PDIF module. I downloaded the specs from Analog Devices and found the register responsible for this, modified the AC97 codec drivers to add a control for the 3 flags specific to this chip (ie. outside of the ac97 specification) concerning the digital interface and managed to turn it on. I would like to submit this modification so that others who may have a similar setup can use it. So my question is : what's next? Who can merge such patches to the CVS tree and what is the validation and/or testing procedure? Or do I just mail the code to 'perex' and he takes care of it? just send the patch to alsa-devel ML. (or you can send to Jaroslav or me directly, too, if you don't show the patch publicly :) we'll review the patch and soon commit to cvs if it's ok. ciao, 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: YES! :-) Was: [Alsa-devel] Bug: ALSA Sequencer or MTPAV - easy to reproduce
The information about the emagic unitor8 has also this Der Befehl F5 gefolgt von einem Datenbyte bestimmt die gerade aktive Kabelnummer (0,1,2,3 ... 64). Ist die Kabelnummer=0 werden alle MIDI Messages auf allen MIDI Outs ausgegeben (alle Outs von allen Boxen). Nach einem Kaltstart ist die Kabelnummer=0. Die Kabelnummer '7F' (dumme MIDI Schnittstelle) verhaelt sich wie die Kabelnummer 0. Kabelnummer '7F' sollte beim Verlassen von LOGIC gesendet werden, da dadurch moegliche Filter(MIDI In/Out) geloescht werden. Siehe MOTU: Mute NON-CHANNEL Messages. Since this device is supposed to be compatible with the MOTU (or have a motu-compatible mode) the documentation at http://www.math.tu-berlin.de/~sbartels/unitor/unitor8_doc.txt could maybe help Immanuel *** I have always been fascinated by those who want to work. Prunesquallor - Ghormenghast Immanuel Litzroth Software Development Engineer Enfocus Software Kleindokkaai 3-5 B-9000 Gent Belgium Voice: +32 9 269 23 90 Fax : +32 9 269 16 91 Email: [EMAIL PROTECTED] web : www.enfocus.be *** --- 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] emu10k1 bug and patch (0.9.0rc7)
At Mon, 10 Feb 2003 18:21:12 +0100,
Arnaud de Bossoreille de Ribou wrote:
Hi, I discovered a bug in the emu10k1 driver which I'll explain here:
I was developing an application which uses the timestamps given in the
status of the device to send S/PDIF data to it. This app worked pretty
well except that sometimes I heard sound discontinuities and then a
constant time delay between the sound and the video.
I finally found where was the problem, my results is based on the
emu10k1-debug.patch file attached. The frame argument is equal to 0
when the app gets the status of the device. With this patch applied I
saw some output on the console exactly at the same time the bug occured.
Adding a else after the if to prevent sw_ready from being updated
fixed the problem and the output looked like
plop 0 -1536 A B
plop 0 1536 B A
where B == A - 1536 (1536 is the period_size). These two lines were
repeated a few times during playback.
So the bug looks like a signedness problem since sw_ready is unsigned
and there is a while(sw_ready 0), which explain the constant delay,
next in the snd_emu10k1_fx8010_playback_transfer function.
this is because of the incorrect check of boundary-wrap.
the comparison below must be = instead of .
(or, it can be simply diff 0.)
if there only two periods, the original code cannot detect the
boundary-wrap.
if (diff) {
== if (diff -(snd_pcm_sframes_t) (runtime-boundary / 2))
diff += runtime-boundary;
pcm-sw_ready += diff;
}
sw_ready should be unsigned safely.
please try the change above with the unsigned sw_ready.
anyway, thanks for your bug report!
ciao,
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: YES! :-) Was: [Alsa-devel] Bug: ALSA Sequencer or MTPAV - easy to reproduce
At 13 Feb 2003 12:54:39 +0100, Immanuel Litzroth wrote: The information about the emagic unitor8 has also this Der Befehl F5 gefolgt von einem Datenbyte bestimmt die gerade aktive Kabelnummer (0,1,2,3 ... 64). Ist die Kabelnummer=0 werden alle MIDI Messages auf allen MIDI Outs ausgegeben (alle Outs von allen Boxen). Nach einem Kaltstart ist die Kabelnummer=0. Die Kabelnummer '7F' (dumme MIDI Schnittstelle) verhaelt sich wie die Kabelnummer 0. Kabelnummer '7F' sollte beim Verlassen von LOGIC gesendet werden, da dadurch moegliche Filter(MIDI In/Out) geloescht werden. Siehe MOTU: Mute NON-CHANNEL Messages. Since this device is supposed to be compatible with the MOTU (or have a motu-compatible mode) the documentation at http://www.math.tu-berlin.de/~sbartels/unitor/unitor8_doc.txt could maybe help Immanuel oh, where did you get it? it's really helpful. with this we can implement the init and smpte sysex code on mtpav driver. also unitor8 can be supported, too. thanks! 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] dmix plugin
At Wed, 12 Feb 2003 20:21:31 +0100 (CET), Jaroslav wrote: On Wed, 12 Feb 2003, Marc Titinger wrote: This looks Great ! I haven't yet experimented a lot with .asoundrc files, so please excuse me if the following questions are irrelevant or OTO, but: I was wondering if one could define a plug pcm, that offers two stereo pairs routed with policy average to a single-stereo hw slave. My understanding is that until this dmix pcm, there was no official means supported by alsalib to achieve software mix of streams comming from differents apps. Yes, that's true. well, route (or plug) has the capability for software mix (in a certain meaning), but not for separate pcm streams. you can downmix the multi-channels in a stream via route plugin if the channels is given. but it's defenitely different from what dmix plugin does, and perhaps it's different from what Marc wants, too... Could I have one app open the first pair of my hypothetic plug pcm, and another app open the second pair ? I guess this would be managed like a concurrent access to a pcm, and block or fail the second open() call. Would'nt it be nice to create a dmix pcm behind a such plug pcm, to provide mix in a transparent way ? Some cards with multiple open hardware acceleration doesn't need this default. Also, the dmix plugin has some limited things so I don't prefer to select it as default. agreed here, although i feel it's also nice to set it as default for a consumer card which has no hardware mix function. please note that you can re-define the default in asoundrc. if you want to set up dmix as the system default, you can define it in /etc/asound.conf, too. 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] RME installation problems
On Thu, Feb 13, 2003 at 12:13:46PM +0100, Takashi Iwai wrote: At Thu, 13 Feb 2003 12:08:51 +0100, Martin Langer wrote: On Thu, Feb 13, 2003 at 11:44:24AM +0100, Orm Finnendahl wrote: Hi Takashi, Am Donnerstag, den 13. Februar 2003 um 10:31:09 Uhr (+0100) schrieb Takashi Iwai: ie add the 0xb revision. Yes. In the old driver it just checks for 0xa and 0x64. Just add a line to also check for 0xb. but i don't see any 0x64 there... There was a mail by Justin few weeks ago, talking about the rev. 0x64. http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg05383.html Looks like, that this solution doesn't find it's way into CVS. Justin, can you send us a patch of your work? anyway, check the attached patch. is it correct? Sorry, I don't have such a hardware. martin --- 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] dmix plugin
well, route (or plug) has the capability for software mix (in a certain meaning), but not for separate pcm streams. you can downmix the multi-channels in a stream via route plugin if the channels is given. but it's defenitely different from what dmix plugin does, and perhaps it's different from what Marc wants, too... You got my point : route may looks like soft mix, but actually is downmix with the possibility of setting gains. I guess gains are what makes sense using the asoundrc configuration instead of leaving the downmix to the plughw (I assume plughw would downmix a stereo stream to a mono hw pcm, even if nothing is asoundrc-configured). Some cards with multiple open hardware acceleration doesn't need this default. Also, the dmix plugin has some limited things so I don't prefer to select it as default. agreed here, although i feel it's also nice to set it as default for a consumer card which has no hardware mix function. please note that you can re-define the default in asoundrc. if you want to set up dmix as the system default, you can define it in /etc/asound.conf, too. This makes me enthousiastic about those configuration files : it's a pity that no GUI is yet available to help design complex files ; consider the fact that some hardware manufacturers spend time on developping pricy console enabled hardware, console interfaces and SDK. A good GUI for asoundrc wouldn't be far from a console interface, especially if some settings can be automated via the sequencer : imagine a gain (or any parameter) could be dependent of a MIDI code ! --- 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] playing underruns
Thanks for responding Paul. I'm using Red Hat 7.2 which is the 2.4 kernel and the 0.9.0rc7 ALSA driver. I'm not sure why you want to know about the disk controller since there is no disk access in the real-time part of my application. But I am using a Dell Inspiron 8200 and I looked on the web at the spec sheet which describes the disk as Ultra ATA. They didn't have any info about controllers unless ATA is some kind of controller. I think I have heard about the low latency patch. My understanding about that is that it is for more precise delivery of signals. That is, more precise than the .01 secs promised and usually delivered by Linux. With the current signal delivery my sound samples still get written well before they should be played. I am writing samples .05 secs before they time they should actually move the speaker while my signals are only rarely any later than .02 secs after the time requested. Of course, I have no idea what must happen between the time I write the samples and when they actually are turned into sound. 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] MTP-AV problems (Re: intel8x0 sequencer MTP-AV)
Hi Allan, recently a technical information about emagic unitor8 was revealed, and it includes a small desription about MTP, too. there, the initialization sysex is mentionted, so perhaps this may influence on the behavior of the device. (also, the smpte sysex is described!) before i start coding, i would like to ask you summarize the existing problems of mtpav driver (which most likely i forgot :) i hope this time the bugs can be fixed, or at least improved... ciao, Takashi --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] playing underruns
trying to summarize 3-4 years of experience with this is hard. but lets start by pointing out that its possible that your disk controller causes the kernel to delay scheduling for up to 100msecs. i'm not sure if RH7 fixed this by setting the driver parameters correctly - i have heard that newer versions of RH do this. IDE/ATA drives have been notorious under linux for ruining any soft-real-time performance. and yes, your program may do no disk i/o, but that doesn't mean none is going on. you need to run hdparm to get the driver parameters, and also check if you have a file /proc/sys/kernel/lowlatency. --p ps. and BTW, in my regularly scheduled plug, please, please take a look at jackit.sf.net for a much easier and more useful way to write audio apps for linux. and now, back to our program! --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] cvs.alsa-project.org access problems
Hello, I am experiencing lots of problems accessing cvs.alsa-project.org bitone:~/alsa-cvs# cvs update alsa-lib cvs [update aborted]: end of file from server (consult above messages if any) bitone:~/alsa-cvs# cvs update alsa-lib cvs [update aborted]: reading from server: Connection reset by peer Sometimes these errors occur only occasionally, but in the last half an hour I have not been able to do an update. I don't know if this is a sourceforge problem in general, but it certainly is annoying. Is anybody else having these difficulties? Maarten --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] MTP-AV problems (Re: intel8x0 sequencer MTP-AV)
recently a technical information about emagic unitor8 was revealed, I suppose this doesn't mention AMT? Can I have this information. It might contain more than what I already have. and it includes a small desription about MTP, too. there, the initialization sysex is mentionted, so perhaps this may influence on the behavior of the device. (also, the smpte sysex is described!) I think both devices act as a single MIDI device where the 0xf5 message that is undefined in the MIDI spec is used for cable selection. Thus the running status is for the MIDI stream and not per cable. I don't think these devices use running status on transmitting (to the host at least) themselves. before i start coding, i would like to ask you summarize the existing problems of mtpav driver (which most likely i forgot :) i hope this time the bugs can be fixed, or at least improved... Is it possible to open files from the kernel? I'd suggest having support for devices like the Unitor in user-space to be able to support them on any serial port if this is not the case. --ms --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] MTP-AV problems (Re: intel8x0 sequencer MTP-AV)
At Thu, 13 Feb 2003 16:05:00 +0100, Martijn Sipkema wrote: recently a technical information about emagic unitor8 was revealed, I suppose this doesn't mention AMT? Can I have this information. It might contain more than what I already have. the info appeared in another thread (running-status bug on mtpav): http://www.math.tu-berlin.de/~sbartels/unitor/unitor8_doc.txt the project itself seems dead now... and it includes a small desription about MTP, too. there, the initialization sysex is mentionted, so perhaps this may influence on the behavior of the device. (also, the smpte sysex is described!) I think both devices act as a single MIDI device where the 0xf5 message that is undefined in the MIDI spec is used for cable selection. Thus the running status is for the MIDI stream and not per cable. I don't think these devices use running status on transmitting (to the host at least) themselves. yes, this bug was discussed in another thread. before i start coding, i would like to ask you summarize the existing problems of mtpav driver (which most likely i forgot :) i hope this time the bugs can be fixed, or at least improved... Is it possible to open files from the kernel? I'd suggest having support for devices like the Unitor in user-space to be able to support them on any serial port if this is not the case. generally i agree that a user-space driver would be flexible for serial devices. but there is already a working mtpav driver and if only a small amount of changes would be needed, why not? the support of usb would be a different thing... Takashi --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] MTP-AV problems (Re: intel8x0 sequencer MTP-AV)
[...] I suppose this doesn't mention AMT? Can I have this information. It might contain more than what I already have. the info appeared in another thread (running-status bug on mtpav): http://www.math.tu-berlin.de/~sbartels/unitor/unitor8_doc.txt the project itself seems dead now... That's the info I already had... :( I don't see why Emagic won't give the AMT protocol specs... --ms --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] A simple question, Alsa on debian
Yes, and thanks for the help, It seems to work to compile the source from the tarball
the ordinary way also.
Progress-report on the es18xx.c on ES1878:
* I found the nd_es18xx_dsp_get_byte() to be inconsistent with the spec. and rewrote
it accordingly.
static int snd_es18xx_dsp_get_byte(es18xx_t *chip)
{
int i;
for(i = 0; i = MILLISECOND; i++)
if ((inb(chip-port + 0xE) 0x80))
return inb(chip-port + 0xA);
}
* My goal would be to modify as little as possible to get is working by the way.
* Now I have discovered the following: by modifying snd_es18xx_playback_prepare() and
snd_es18xx_playback_trigger() by hardcoding what function to choose I got some static
sounds out of the chip by the following:
--Combine snd_es18xx_playback2_prepare() with snd_es18xx_playback1_trigger gives
static when playing a file in kern.log.
--Combine snd_es18xx_playback1_prepare() with snd_es18xx_playback2_trigger gives
static and bug write in kern.log.
(by the way any other combination gives no sound at all for me such as combining
snd_es18xx_playback2_prepare() with snd_es18xx_playback2_trigger)
This would entail that the problems could be in the prepare functions, since the mixer
controls seem to respond with lowering/raising the output.
Best regards from Erik
_
Här börjar internet!
Skaffa gratis e-mail och gratis internet på http://www.spray.se
Träffa folk från hela Sverige på ett och samma ställe - http://chat.spray.se/
Re: [Alsa-devel] RME installation problems
On Thu, 2003-02-13 at 13:18, Martin Langer wrote:
On Thu, Feb 13, 2003 at 12:13:46PM +0100, Takashi Iwai wrote:
At Thu, 13 Feb 2003 12:08:51 +0100,
Martin Langer wrote:
On Thu, Feb 13, 2003 at 11:44:24AM +0100, Orm Finnendahl wrote:
Hi Takashi,
Am Donnerstag, den 13. Februar 2003 um 10:31:09 Uhr (+0100) schrieb
Takashi Iwai:
ie add the 0xb revision.
Yes. In the old driver it just checks for 0xa and 0x64. Just add a
line to also check for 0xb.
but i don't see any 0x64 there...
There was a mail by Justin few weeks ago, talking about the rev. 0x64.
http://www.mail-archive.com/alsa-devel@lists.sourceforge.net/msg05383.html
Looks like, that this solution doesn't find it's way into CVS.
Justin, can you send us a patch of your work?
it was just
Index: alsa-kernel/pci/rme9652/hdsp.c
===
RCS file: /suse/tiwai/cvs/alsa/alsa-kernel/pci/rme9652/hdsp.c,v
retrieving revision 1.20
diff -u -r1.20 hdsp.c
--- alsa-kernel/pci/rme9652/hdsp.c 7 Feb 2003 09:18:41 -
1.20
+++ alsa-kernel/pci/rme9652/hdsp.c 13 Feb 2003 11:12:26 -
@@ -2981,6 +2981,7 @@
switch (rev 0xff) {
case 0xa:
+ case 0x64:
/* hdsp_initialize_firmware() will reset this */
hdsp-card_name = RME Hammerfall DSP;
break;
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] pcm_jack plugin attempt
I wrote: The problem I described in my previous mail (no more calls to snd_pcm_jack_mmap_commit after start) still occurs though... Any idea what might be the problem, or where to look? Okay, I fixed this. It was a missing pcm-poll_events = POLLIN; (after pcm-poll_fd = fd[1] , in snd_pcm_jack_open) Can you fix this in CVS? Playback now works nicely, including the polling. Going to add capture now. Maarten --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [PATCH]: Bug: ALSA Sequencer or MTPAV - easy toreproduce
On Thu, 13 Feb 2003, Takashi Iwai wrote: Hi, At Wed, 12 Feb 2003 14:35:29 -0800, Ryan Pavlik wrote: On Wed, 12 Feb 2003 21:41:50 +0100 (CET) Jaroslav Kysela [EMAIL PROTECTED] wrote: snip It seems that mtpav don't remeber the old status byte for each channels. If it's true, then we need to take care about the expansion in the mtpav driver, because the sequencer MIDI driver removes duplicated status bytes to opmitize throughput. snip OK, I've attached a patch that emulated running status in the mtpav driver, so there shouldn't be any need to change stuff elsewhere. Thanks for your pointer, I've been wanting to fix this problem for a very long time. :-) thanks for the patch. i applied it to cvs with a little improvement (returning immediately if snd_rawmidi_transmit() gets null). also, i found a bug regarding magic-alloc/free in the driver (at last!). fixed on cvs, too. Unfortunately, the patch is not perfect. I think that we need to buffer the whole MIDI message and send it after completion, because it's possible, that you'll get only partial MIDI message from the rawmidi API or at buffer overrun / full. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] dmix plugin
On Thu, 13 Feb 2003, Takashi Iwai wrote: agreed here, although i feel it's also nice to set it as default for a consumer card which has no hardware mix function. We can add the special configuration to card-specific configuration files (like for surround*, spdif etc.), but I was too lazy to do it ;-) Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] dev advise needed
Hello,
I am working on adding native alsa support to the Helix project, and am
running into issues I think are with threading between the two.
Mainly, variable values are returning as 0 when they shouldn't be.
such as
function(int bleh) {
bleh = 1;
}
when function() returns, bleh == 0 in the calling function, I have used
valgrind to show me that it is trying to access unaccessable variables.
Now, both helix and alsa are threaded. and helix works fine with the oss
implementation.
Helix locks and unlocks when needed.
I havent done a all that much of threaded programming, any suggestions
on what I should look into? or hints at solving this?
thx,
ljp
--
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: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] pcm_jack plugin attempt
Attached you find the patch with my latest changes. Both playback and capture from jack work now, though not simultanously. $ jackd -d alsa -p 4096 -d hw:0 $ aplay -Dmyplug /usr/share/sounds/KDE_Startup.wav $ arecord -Dmyplug -d 4 foo.wav (see my previous mail on how to define myplug) Now, my next problem is linked playback/capture $ ./latency -m 4096 -M 4096 t 1 -p -e -C myplug -P myplug [...] ALSA lib pcm.c:1127:(snd_pcm_link) SNDRV_PCM_IOCTL_LINK failed: Bad address Streams link error: Bad address Suggestions? Maarten pcm_jack_capture.patch Description: Binary data
Re: [Alsa-devel] [PATCH]: Bug: ALSA Sequencer or MTPAV - easy toreproduce
On Thu, 13 Feb 2003 17:27:25 +0100 (CET) Jaroslav Kysela [EMAIL PROTECTED] wrote: snip Unfortunately, the patch is not perfect. I think that we need to buffer the whole MIDI message and send it after completion, because it's possible, that you'll get only partial MIDI message from the rawmidi API or at buffer overrun / full. snip Actually I have thought of this off and on, and figured that it would probably be a Bad Thing: 1) It'd be painful to implement. The mtpav driver would need a full understanding of MIDI, which means reimplementing things that are already there at higher levels. - You need to know the length of each message - You can't rely on finding the next status 0x80, because it might not arrive right away - Buffering large Sysex dumps would suck ;) - Other messages you don't understand might not get through 2) More importantly: buffering would increase latency, which is always the reason I don't sit down and start coding. It's true that it would be nice to be able to send partial messages, though, but most things use the ALSA sequencer API anyway. -- Ryan Pavlik [EMAIL PROTECTED] Oh for the love of evil, not this again. - 8BT --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] playing underruns
Paul, Again thanks very much. From: /sbin/hdparm /dev/hda2 I get: /dev/hda2: multcount = 16 (on) I/O support= 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) nowerr = 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 4864/255/73, sectors = 36869175, start = 4225095 with similar results for the other hda's. I don't know if this is the question you were asking, though, since this doesn't seem to have much info. I don't have the low latency patch. I will take a look at jackit.sf.net. However, I am close to having the sound I/0 working the way I need it to, so I am a little reluctant to start all over. :) Chris --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] playing underruns
Also check out the Planet for more info on this. Fernando has some suggestions for Redhat there. Cheers, Mark -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Paul Davis Sent: Thursday, February 13, 2003 11:11 AM To: Chris Raphael Cc: [EMAIL PROTECTED] Subject: Re: [Alsa-devel] playing underruns /sbin/hdparm /dev/hda2 I get: /dev/hda2: multcount = 16 (on) I/O support = 0 (default 16-bit) unmaskirq = 0 (off) using_dma = 1 (on) keepsettings = 0 (off) nowerr= 0 (off) readonly = 0 (off) readahead = 8 (on) geometry = 4864/255/73, sectors = 36869175, start = 4225095 with similar results for the other hda's. I don't know if this is the question you were asking, though, since this doesn't seem to have much info. yep, this doesn't look too good, though its not a complete disaster. please read this: http://linux.oreillynet.com/pub/a/linux/2000/06/29/hdparm.html keep in mind that some distributions (RH included, i think) have fixed this issue somewhat, though they may not have gone far enough for low latency audio. I don't have the low latency patch. you will probably need it. the standard kernel in RH7 is not up to the task. --p --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] emu10k1 bug and patch (0.9.0rc7)
On Thu, 13 Feb 2003, Takashi Iwai wrote:
At Mon, 10 Feb 2003 18:21:12 +0100,
Arnaud de Bossoreille de Ribou wrote:
Hi, I discovered a bug in the emu10k1 driver which I'll explain here:
I was developing an application which uses the timestamps given in the
status of the device to send S/PDIF data to it. This app worked pretty
well except that sometimes I heard sound discontinuities and then a
constant time delay between the sound and the video.
I finally found where was the problem, my results is based on the
emu10k1-debug.patch file attached. The frame argument is equal to 0
when the app gets the status of the device. With this patch applied I
saw some output on the console exactly at the same time the bug occured.
Adding a else after the if to prevent sw_ready from being updated
fixed the problem and the output looked like
plop 0 -1536 A B
plop 0 1536 B A
where B == A - 1536 (1536 is the period_size). These two lines were
repeated a few times during playback.
So the bug looks like a signedness problem since sw_ready is unsigned
and there is a while(sw_ready 0), which explain the constant delay,
next in the snd_emu10k1_fx8010_playback_transfer function.
this is because of the incorrect check of boundary-wrap.
the comparison below must be = instead of .
(or, it can be simply diff 0.)
if there only two periods, the original code cannot detect the
boundary-wrap.
if (diff) {
== if (diff -(snd_pcm_sframes_t) (runtime-boundary / 2))
diff += runtime-boundary;
pcm-sw_ready += diff;
}
sw_ready should be unsigned safely.
please try the change above with the unsigned sw_ready.
Not really. Note that the application can move the appl_ptr backward
(using snd_pcm_rewind()). The problem is that pcm-appl_ptr is updated
wrongly, thus calling function with frames == 0 twice or more causes
different results. I'm working on a proper fix.
Jaroslav
-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] playing underruns
Paul, Okay I looked at the page you pointed me to with info about hdparm. before I changed any of the controller settings I got 21.12 MB/sec for Timing buffered disk reads which seems to be pretty good according to the author of the web page. After changing the settings (I/O support 32 bit, unmaskirq = on, transfer mode to UltraDMA) no change. I think my program is not adversely affected by any disk access since I always check to see when my program's callbacks are actually delivered. They seem to be accurate enough and almost never more that .02 secs later than requested. My sense is that I am writing my samples on time (as far as I can measure) and the problem happens somewhere in the chain of events *after* my program writes audio samples. Do you think the lowlatency patch might help there? Or any other ideas? Chris --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [PATCH]: Bug: ALSA Sequencer or MTPAV - easy toreproduce
On Thu, 13 Feb 2003, Ryan Pavlik wrote: On Thu, 13 Feb 2003 17:27:25 +0100 (CET) Jaroslav Kysela [EMAIL PROTECTED] wrote: snip Unfortunately, the patch is not perfect. I think that we need to buffer the whole MIDI message and send it after completion, because it's possible, that you'll get only partial MIDI message from the rawmidi API or at buffer overrun / full. snip Actually I have thought of this off and on, and figured that it would probably be a Bad Thing: 1) It'd be painful to implement. The mtpav driver would need a full understanding of MIDI, which means reimplementing things that are already there at higher levels. - You need to know the length of each message - You can't rely on finding the next status 0x80, because it might not arrive right away - Buffering large Sysex dumps would suck ;) - Other messages you don't understand might not get through 2) More importantly: buffering would increase latency, which is always the reason I don't sit down and start coding. It's true that it would be nice to be able to send partial messages, though, but most things use the ALSA sequencer API anyway. The problem is that the driver is still buggy (only a bit less probably) and output will not be correct under some circumstances. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] pcm_jack plugin attempt
On Thu, 13 Feb 2003, Maarten de Boer wrote: Attached you find the patch with my latest changes. Both playback and capture from jack work now, though not simultanously. $ jackd -d alsa -p 4096 -d hw:0 $ aplay -Dmyplug /usr/share/sounds/KDE_Startup.wav $ arecord -Dmyplug -d 4 foo.wav (see my previous mail on how to define myplug) Now, my next problem is linked playback/capture $ ./latency -m 4096 -M 4096 t 1 -p -e -C myplug -P myplug [...] ALSA lib pcm.c:1127:(snd_pcm_link) SNDRV_PCM_IOCTL_LINK failed: Bad address Streams link error: Bad address Suggestions? The snd_pcm_link() uses special ioctl() directly and only the ALSA driver knows it. I'll try to fix this problem when I'll get some time, because also the dmix plugin needs this fix. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] emu10k1 bug and patch (0.9.0rc7)
On Mon, 10 Feb 2003, Arnaud de Bossoreille de Ribou wrote:
So the bug looks like a signedness problem since sw_ready is unsigned
and there is a while(sw_ready 0), which explain the constant delay,
next in the snd_emu10k1_fx8010_playback_transfer function.
So the emu10k1.patch file attached fixes the problem and seems not to
introduce new ones.
Please, could you try this patch, if it also fixes your problem? Thanks.
Index: emufx.c
===
RCS file: /cvsroot/alsa/alsa-kernel/pci/emu10k1/emufx.c,v
retrieving revision 1.26
diff -u -r1.26 emufx.c
--- emufx.c 31 Jan 2003 15:21:03 - 1.26
+++ emufx.c 13 Feb 2003 20:29:55 -
@@ -532,7 +532,7 @@
if (diff) {
if (diff -(snd_pcm_sframes_t) (runtime-boundary / 2))
diff += runtime-boundary;
- pcm-sw_ready += diff;
+ frames += diff;
}
pcm-sw_ready += frames;
pcm-appl_ptr = appl_ptr + frames;
Jaroslav
-
Jaroslav Kysela [EMAIL PROTECTED]
Linux Kernel Sound Maintainer
ALSA Project, SuSE Labs
---
This SF.NET email is sponsored by: FREE SSL Guide from Thawte
are you planning your Web Server Security? Click here to get a FREE
Thawte SSL guide and find the answers to all your SSL security issues.
http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] libasound dies on snd_pcm_open
Hi again,
seems I was following a red herring. My debugger mislead me.
The function 'snd_pcm_open()' isn't the culprit, it really dies here:
==
int rc = 0;
int exactRate
= snd_pcm_hw_params_set_rate_near (capture_handle, hw_params,
uSampleRate, rc);
if(rc != 0) {
==
With the following definitions, declarations:
unsigned int uSampleRate - value 16100;
snd_pcm_t *capture_handle;
snd_pcm_hw_params_t *hw_params;
//ALSA library
#define ALSA_PCM_NEW_HW_PARAMS_API
#include alsa/asoundlib.h
It never returns from the call to snd_pcm_hw_params_set_rate_near and the
cpu is maxing out.
What I'm doing wrong? I'm really clueless now.
You can see from the attached text file what I've been trying...
Any help really appreciated.
Thanks,
Meinhard
int KCorrView::openALSADevice(){
int rc = 0;
snd_pcm_hw_params_t *hw_params;
const char *cTemp = 0;
//snd_pcm_access_t access = ;
cTemp = sDevice.ascii();
std::cerr sDevice std::endl;
if ((rc = snd_pcm_open (capture_handle, sDevice.ascii(),
SND_PCM_STREAM_CAPTURE, 0)) 0) {
std::cerr cannot open audio device sDevice snd_strerror (rc);
return rc;
}
/* if ((rc = snd_pcm_hw_params_malloc (hw_params)) 0) {
std::cerr cannot allocate hardware parameter structure snd_strerror (rc);
return rc;
} */
snd_pcm_hw_params_alloca (hw_params);
if ((rc = snd_pcm_hw_params_any (capture_handle, hw_params)) 0) {
std::cerr cannot initialize hardware parameter structure snd_strerror (rc);
return rc;
}
if ((rc = snd_pcm_hw_params_set_access (capture_handle, hw_params, SND_PCM_ACCESS_RW_INTERLEAVED)) 0) {
// cerr cannot set access type snd_strerror (rc);
return rc;
}
if ((rc = snd_pcm_hw_params_set_format (capture_handle, hw_params, SND_PCM_FORMAT_S16_LE)) 0) {
std::cerr cannot set sample format snd_strerror (rc);
return rc;
}
if ((rc = snd_pcm_hw_params_set_channels(capture_handle, hw_params, 2)) 0) {
std::cerr Could not set to stereo snd_strerror(rc) std::endl;
return rc;
}
/* int exactRate
= snd_pcm_hw_params_set_rate_near (capture_handle, hw_params, uSampleRate, rc);
if(rc != 0) {
std::cerr Sample rate uSampleRate is'nt supported by your hardware. Using
exactRate Hz instaed. std::endl;
}
std::cout snd_pcm_hw_params_set_rate_near returned with:exactRate std::endl;
*/
unsigned int rrate = uSampleRate;
if((rc = snd_pcm_hw_params_set_rate_near (capture_handle, hw_params, rrate, 0)) 0){
std::cerr Failed to set sample rate: uSampleRate snd_strerror (rc);
}
if(rrate != uSampleRate) {
std::cerr Sample rate uSampleRate is'nt supported by your hardware. Using
rrate Hz instaed. std::endl;
}
std::cout snd_pcm_hw_params_set_rate_near returned with:rc std::endl;
if ((rc = snd_pcm_hw_params_set_channels (capture_handle, hw_params, 2)) 0) {
std::cerr cannot set channel count snd_strerror (rc);
return rc;
}
if ((rc = snd_pcm_hw_params (capture_handle, hw_params)) 0) {
std::cerr cannot set parameters snd_strerror (rc);
return rc;
}
snd_pcm_hw_params_free (hw_params);
if ((rc = snd_pcm_prepare (capture_handle)) 0) {
std::cerr cannot prepare audio interface for use snd_strerror (rc);
return rc;
}
std::cout successfully set up ALSA 0.9 device std::endl;
char buf[512];
long a;
if ((a = snd_pcm_readi (capture_handle, buf, 128)) 0) {
std::cerr read from audio interface failed: snd_strerror (a) std::endl;
return -1;
}
/*
for(int i=0; i 128; i++){
std::cout buf[i];
}
std::cout std::endl;
*/
return rc;
}
Re: [Alsa-devel] libasound dies on snd_pcm_open
On Thu, 13 Feb 2003, M. Ritscher wrote: Hi again, seems I was following a red herring. My debugger mislead me. The function 'snd_pcm_open()' isn't the culprit, it really dies here: Before we start any debugging - are you using the alsa-lib from CVS? I've fixed some problems which may relate to your report a few days ago. Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Trident problems.
(cvs version 2003-02-13) /sbin/modprobe snd-trident Note: /etc/modules.conf is more recent than /lib/modules/2.4.19/modules.dep /lib/modules/2.4.19/kernel/sound/pci/trident/snd-trident.o: init_module: No such device 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 /lib/modules/2.4.19/kernel/sound/pci/trident/snd-trident.o: insmod /lib/modules/2.4.19/kernel/sound/pci/trident/snd-trident.o failed /lib/modules/2.4.19/kernel/sound/pci/trident/snd-trident.o: insmod snd-trident failed [root@pescadero Documentation]# And dmsg: ALSA ../../alsa-kernel/pci/trident/trident_main.c:3382: AC'97 codec ready error [0x0] Trident 4DWave PCI soundcard not found or device busy What can make it busy? From /proc/pci Bus 0, device 11, function 0: Multimedia audio controller: Trident Microsystems 4DWave NX (rev 2). IRQ 17. Master Capable. Latency=32. Min Gnt=2.Max Lat=5. I/O at 0x9400 [0x94ff]. Non-prefetchable 32 bit memory at 0xd300 [0xd3000fff]. I have not had this card running for a year or so. The machine runs on a dual PII with SMP kernel. The other soundcard a SB-PCI128 works fine. --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Broken pipe mystery
On Thu, 2003-02-13 at 12:56, Pete Barnard wrote: : Does it always crash after the same time? No. It didin't crash after the same time. The problem is fixed now thanks to Josh Green's tip. (I wrote a function that caught the EPIPE error and then did a snd_pcm_prepare). I left it for 2 nights with a system(date) in the catch function and got an EPIPE once on one night and not at all on the second night - so even though it is fixed I'm still slightly curious as to why I got this problem/feature at all. Regards, Pete Its due to your program not being able to meet the deadline for writing an audio buffer for playback. This is often Linux kernel related and there is lots of information about tuning your kernel (do a search for linux kernel low latency). It can be somewhat of a black art, because different hardware and Linux drivers can have adverse effects on latency. For instance if your hard disk is IDE and isn't tuned right (DMA not enabled for instance) you can get real long latency spikes when reading/writing the hard disk. You'll also want to look into the lowlat patch and perhaps the preempt patch as well. Kernels that come with Linux distributions have a tendency to not be very low latency friendly, so if you wan't low latency, build your own kernel with one of those patches. On your program side: You can increase the audio buffer size and/or count to minimize underruns (at the cost of higher latency audio playback). If you require low latency, run your program with SCHED_FIFO scheduling (see man sched_setscheduler, requires root privileges). Note that your program then has the ability to lock up the machine, should it decide to consume all the CPU time. I think this is one of the main things that still needs to be solved with Linux and audio. Low latency audio shouldn't entail buggy processes being able to bring the system to its knees. Cheers. Josh Green --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: MTP-AV problems (Re: intel8x0 sequencer MTP-AV)
Hi Takashi This is fantastic news!! I haven't got a working build of MusE probably until later this weekend. I have to go and engineer a gig later today and I'm sick today so I can't seem myself doing much till tomorrow. Basically it seemed to receive timecode (MIDI CLOCK and MTC) okay from our earlier testing. It also would send MIDI to one output port. The device stopped seeing all messages when attempts at sending MIDI output to more than one port occured.(this is where the initialisation SYSEX probably comes into play) MIDI Input was not registering on the computer hence recording did not work. cheers Allan On Fri, 2003-02-14 at 01:34, Takashi Iwai wrote: Hi Allan, recently a technical information about emagic unitor8 was revealed, and it includes a small desription about MTP, too. there, the initialization sysex is mentionted, so perhaps this may influence on the behavior of the device. (also, the smpte sysex is described!) before i start coding, i would like to ask you summarize the existing problems of mtpav driver (which most likely i forgot :) i hope this time the bugs can be fixed, or at least improved... ciao, Takashi --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] libasound dies on snd_pcm_open
Hi Jaroslav, Before we start any debugging - are you using the alsa-lib from CVS? I've fixed some problems which may relate to your report a few days ago. No, I'm using 0.9rc7. Seems I have to make myself familiar with using the CVS version than. Cheer, Meinhard -- +++ GMX - Mail, Messaging more http://www.gmx.net +++ Bitte lächeln! Fotogalerie online mit GMX ohne eigene Homepage! --- This SF.NET email is sponsored by: FREE SSL Guide from Thawte are you planning your Web Server Security? Click here to get a FREE Thawte SSL guide and find the answers to all your SSL security issues. http://ads.sourceforge.net/cgi-bin/redirect.pl?thaw0026en ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
RE: [Alsa-devel] IEEE 1394
Pavel, You're in the wrong forum. Go to www.linux1394.org and pick up the information you need to get started there. If you want to develop 1394 applications there are some mailing lists there with other like minded people. Good luck, Mark -Original Message-From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of PavelSent: Thursday, February 13, 2003 4:34 AMTo: [EMAIL PROTECTED]; [EMAIL PROTECTED]Subject: [Alsa-devel] IEEE 1394 Hi, I would like to ask about situation in Linux about one problem. Does Linux kernel or Alsa drivers supports IEEE 1394 standart? If yes, could you recomend me some references and advices to be able to use it andprogram itto createapplications with IEEE 1394? If no, could you recomend me some advices or some documentation to be able to create IEEE 1394 driver? Thanks Ing. Pavel Nikitenko
Re: [Alsa-devel] IEEE 1394
I would like to ask about situation in Linux about one problem. Does Linux kernel or Alsa drivers supports IEEE 1394 standart? If yes, could you recomend me some references and advices to be able to = use it and program it to create applications with IEEE 1394? If no, could you recomend me some advices or some documentation to be = able to create IEEE 1394 driver? for audio+MIDI, there is no fully-defined standard yet. linux already has a compliant 1394 driver, but you normally need extra protocols on top of this for moving specific kinds of data around. IEEE has defined one (IEC61883-6) for audio+MIDI, based on mLAN, and I believe you can get the specs from them or the AES. However, it doesn't support any connection management, so all endpoints have to be explicitly identified by the user, and everything has to be explicitly delivered. Yamaha submitted their scheme for CM to the 1394 trade association as the AV/C Music Subunit. its been released but not implemented (even by Yamaha) because Yamaha are changing mLAN again. Basically, to quote from someone who really knows this stuff: So a streaming driver using a format compatible with mLAN devices is not a problem at this stage - it is possible to direct audio/MIDI to mLAN devices and pick up audio and MIDI, but not in a flexible manner. The connection management architecture first needs to settle. --p ps. just a quick note to point out that whether you know it or not, the email program you are using is sending out copies of your mail in both plain text and HTML formats. increasingly on the net, there are filters being put in place that silently dump HTML-formatted email. some mailing lists will not ever accept such posts. as long as you do this, you are (1) wasting network bandwidth by sending messages that are typically more than twice as long as they could be (2) making it harder for people using traditional email readers to read them (3) risking the chance that people will never see your mail because its filtered before reaching their email inbox. --- 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: [linux-audio-dev] Re: why is no-one responding are you all just a bunch of *^%^%^ wits???
At Wed, 12 Feb 2003 11:49:08 -0500, Paul Davis wrote: when ardour is in a state where i believe (rightly or wrongly) that a reasonably typical target user can sit down and just use it without encountering bugs when recording a typical 12-32 track piece, there will be binaries. don't forget that the binary distribution may cause different kind of problems, too. the binary might not run on different distributions, or even on a different machine with a same distribution, unless you give all-static-linked binary. (note that even a binary like netscape 4.x cannot run properly now with the new glibc because of java.) and you would likely ignore a bug-report for such, because the only answer is it works for me :) Takashi (in a pessmistic atmosphere) --- 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: [linux-audio-dev] Re: why is no-one responding are you all just a bunch of *^%^%^ wits???
don't forget that the binary distribution may cause different kind of problems, too. the binary might not run on different distributions, or even on a different machine with a same distribution, unless you give all-static-linked binary. (note that even a binary like netscape 4.x cannot run properly now with the new glibc because of java.) a 100% statically linked binary will be available, but not recommended. --- 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] IEEE 1394
Hi, I would like to ask about situation in Linux about one problem. Does Linux kernel or Alsa drivers supports IEEE 1394 standart? If yes, could you recomend me some references and advices to be able to use it andprogram itto createapplications with IEEE 1394? If no, could you recomend me some advices or some documentation to be able to create IEEE 1394 driver? Thanks Ing. Pavel Nikitenko
