Re: [Alsa-devel] Improving wine support for alsa.
James, I don't know if this is of any help, but you could always have a peek at the PortAudio (www.portaudio.com) code (pa_linux_alsa.c). We don't use snd_pcm_async_handler though, but implement async and blocking IO ourselves. Hope this helps Arve Knudsen On Thu, 06 May 2004 18:15:56 +, James Courtier-Dutton [EMAIL PROTECTED] wrote: Hi, I have been updating the wine alsa driver to work better with alsa. So far, all I have done is update it to use the new alsa api. Windows uses an api called Direct Sound. Direct Sound uses direct hardware buffer access. A Win32 program can quiry the sound driver and ask for the currently playing position, together with the first available possition that the application could write to. I will call these PlayPos and WritePos respectively. E.g. If the hardware is halfway through playing one period(the PlayPos is in the middle of a period), the beginning of the next period's position is returned as the WritePos. The problem arrives because the Win32 app expects to have full write access to the hardware buffer, and can write to any parts of it at any time. The sound card should just happily move through the buffer playing each sample as it goes, and when it reaches the end, just start at the beginning again. The alsa api is based more around the sound card asking for the next block of samples. Strangely enough, it Direct Sound works fine when using oss emulation in alsa. I was trying to just get alsa to copy samples from the Direct Sound buffer on a just in time basis. I was starting with writing one period to the sound card, calling snd_pcm_start(), then setting snd_async_add_pcm_handler(), expecting the handler to be called on each period, but the handler is never called. For some reason, the handler does not seem to get called on each period elasped as I was expecting. Another problem is that if I want to stop the stream, I call snd_pcm_drop(). With this I would expect snd_pcm_delay()==0 and snd_pcm_avail_update()==buffer_size. It seems that these values are only reset to 0 after first calling snd_pcm_prepare(). After stopping the stream in this way, I want to restart it again without having to close/open the pcm. Can anyone give me advice as to what I am doing wrong ? Cheers James --- This SF.Net email is sponsored by Sleepycat Software Learn developer strategies Cisco, Motorola, Ericsson Lucent use to deliver higher performing products faster, at low TCO. http://www.sleepycat.com/telcomwpreg.php?From=osdnemail3 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Problem deducing buffer time with non-integer samplerate?
Maybe I should add that this is after a successful call to snd_pcm_hw_params (hardwarespace configured), in case it wasn't clear. Does the driver return wrong approximation thresholds (delta 1), or is it supposed to work this way?? I mean, can't ALSA deduce a single approximate value which can be returned? Regards Arve Knudsen On Thu, 04 Mar 2004 14:30:08 +0100, Arve Knudsen [EMAIL PROTECTED] wrote: Hi A PortAudio user has been experiencing a problem with his SB128 (Ensoniq AudioPCI driver), which we tracked down to a call to snd_pcm_hw_params_get_buffer_time returning -EINVAL. A dump of the current hw configuration space looks like this: ACCESS: MMAP_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: (44099 44100) PERIOD_TIME: (5804 5805) PERIOD_SIZE: 256 PERIOD_BYTES: 1024 PERIODS: 5 BUFFER_TIME: (29024 29026) BUFFER_SIZE: 1280 BUFFER_BYTES: 5120 TICK_TIME: 1 Is the problem that the delta between min and max BUFFER_TIME exceeds one (1)? The exact samplerate is 44099.81 which should correlate with the integer min/max values. While I'm at it, is it correct to translate samplerate fractions from 0.5 and upwards to dir == -1 and 1 for fractions less than 0.5 (ie. 44099.81 translates to 44100 with dir == -1)? There's also a bug in the documentation for snd_pcm_hw_params_set_buffer_size, which mentions dir, although its not part of the function signature. Thanks Arve Knudsen --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Problem deducing buffer time with non-integer samplerate?
Hi A PortAudio user has been experiencing a problem with his SB128 (Ensoniq AudioPCI driver), which we tracked down to a call to snd_pcm_hw_params_get_buffer_time returning -EINVAL. A dump of the current hw configuration space looks like this: ACCESS: MMAP_INTERLEAVED FORMAT: S16_LE SUBFORMAT: STD SAMPLE_BITS: 16 FRAME_BITS: 32 CHANNELS: 2 RATE: (44099 44100) PERIOD_TIME: (5804 5805) PERIOD_SIZE: 256 PERIOD_BYTES: 1024 PERIODS: 5 BUFFER_TIME: (29024 29026) BUFFER_SIZE: 1280 BUFFER_BYTES: 5120 TICK_TIME: 1 Is the problem that the delta between min and max BUFFER_TIME exceeds one (1)? The exact samplerate is 44099.81 which should correlate with the integer min/max values. While I'm at it, is it correct to translate samplerate fractions from 0.5 and upwards to dir == -1 and 1 for fractions less than 0.5 (ie. 44099.81 translates to 44100 with dir == -1)? There's also a bug in the documentation for snd_pcm_hw_params_set_buffer_size, which mentions dir, although its not part of the function signature. Thanks Arve Knudsen --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id70alloc_id638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Trying to make gkrellm work with ALSA.
Hi You could always have a look at the v19 (development) branch of PortAudio (www.portaudio.com), which offers an abstraction layer on top of host APIs. ALSA is well supported under v19 (I am one of the authors), while the OSS and JACK layers might need some work (although I'm not totally a jour on their status). Anyway, PortAudio has both callback driven and blocking interfaces, and there is a C++ wrapper called PaCpp (supports class member callbacks from what I remember). If nothing else, you could have a look at how the callback implementation on top of ALSA is done. Hope this helps Arve Knudsen On Wed, 04 Feb 2004 18:29:46 -0600, Nathan Morell [EMAIL PROTECTED] wrote: Hi guys, this is my first note to the list so I'm going to try and get some background information to start on this task. After talking with Bill, the author of gkrellm, I need to find out if ALSA supports 'callbacks' (a new concept in c++ to me). quoted from our email: -- A while back I looked at ALSA 0.9 support for gkrellmss but there was no callback mechanism as there was in ALSA 0.5. Maybe this has changed and I'll look again (let me know if you have any info on this), but short of that, it takes a sound server that provides such callbacks. Currently that's ESD, but I'll probably be adding Jack support fairly soon. -- other then the above, and taking a close look at the original source to the gkrellm-sound plugin, could anybody offer some advice on my project? thanks in advance, --Nathan --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problem with versioned symbols and shared libraries
Ah, thanks. That did the trick indeed. Arve Knudsen On Sat, 17 Jan 2004 12:18:07 +0100 (CET), Jaroslav Kysela [EMAIL PROTECTED] wrote: On Fri, 16 Jan 2004, Rene Rebe wrote: Let's link a normal object and a shared obeject of the ALSAHelper: [EMAIL PROTECTED]:~/develop/trunk/lowlevel/src$ g++ -g -Wall -I. -I../include -I../../dam/include -I../../utility/include -c -o ALSAHelper.o ALSAHelper.cc [EMAIL PROTECTED]:~/develop/trunk/lowlevel/src$ g++ --shared -g -Wall -I. -I../include -I../../dam/include -I../../utility/include -o ALSAHelper.so ALSAHelper.cc I tried that and it seems that you MUST link also this shared module against the asound library: g++ --shared -g -Wall -I. -I../include -I../../dam/include -I../../utility/include -lasound -o ALSAHelper.so ALSAHelper.cc Otherwise the versioned symbol are not applied. Here is the correct nm output: [EMAIL PROTECTED]:~/src/1/svn.rocklinux-consulting.de/gsmp/trunk/lowlevel/src nm ALSAHelper.so | grep snd_pcm_hw_params_get_channels_max U snd_pcm_hw_params_get_channels_max@@ALSA_0.9.0rc4 Have fun, Jaroslav - Jaroslav Kysela [EMAIL PROTECTED] Linux Kernel Sound Maintainer ALSA Project, SuSE Labs --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problem with versioned symbols and shared libraries
Hi, René This is exactly the same problem I'm having with a dynamically linked C++ (extern C) plugin of mine, which links dynamically with ALSA through PortAudio. I made a not so aptly titled post about it earlier, Problem with __OLD_GET. I was still a bit confused as to what was going on .. :) Regards Arve Knudsen On Fri, 16 Jan 2004 20:02:00 +0100 (CET), Rene Rebe [EMAIL PROTECTED] wrote: Hi all, we experience a fairly strange problem with the versioned symbols in the libasound.so. We have a C++ wrapper library which is normally linked as shared obkect, too. But for some strange reasonsthe linker does not map stuff like snd_pcm_hw_params_get_channels_max and friends (with a pointer to the val at the end, now) to the correct symbol. Of course when linked statically into a single binary it works fine. Example log of some testing: Let's link a normal object and a shared obeject of the ALSAHelper: [EMAIL PROTECTED]:~/develop/trunk/lowlevel/src$ g++ -g -Wall -I. -I../include -I../../dam/include -I../../utility/include -c -o ALSAHelper.o ALSAHelper.cc [EMAIL PROTECTED]:~/develop/trunk/lowlevel/src$ g++ --shared -g -Wall -I. -I../include -I../../dam/include -I../../utility/include -o ALSAHelper.so ALSAHelper.cc And now let's link the test application: First the shared object: [EMAIL PROTECTED]:~/develop/trunk2/lowlevel/tests$ g++ -g -Wall -I. -I../include -I../../dam/include -I../../utility/include -o ALSAHelper ALSAHelper.cc ../src/ALSAHelper.so -lasound [EMAIL PROTECTED]:~/develop/trunk2/lowlevel/tests$ ./ALSAHelper Format 16 bit Channels min: 268513264 Channels max: 268513264 Rate min: 0 Rate max: 0 Periods min: 0 Periods max: 0 Period Size: 0 Get periods: 0 Hm - quite incorrect values - let's see which symbol is used: gdb) bt #0 0x0ff433f0 in __old_snd_pcm_hw_params_get_channels_max (params=0x10013498) at pcm.c:6407 #1 0x0ffdc438 in GSMP::ALSAPCM::GetChannelsMax() (this=0x74e0) at ALSAHelper.cc:342 #2 0x10002238 in main () at ALSAHelper.cc:67 Hm - but it works fine linked statically with the normal obcject: [EMAIL PROTECTED]:~/develop/trunk2/lowlevel/tests$ g++ -g -Wall -I. -I../include -I../../dam/include -I../../utility/include -o ALSAHelper ALSAHelper.cc ../src/ALSAHelper.o -lasound [EMAIL PROTECTED]:~/develop/trunk2/lowlevel/tests$ ./ALSAHelper Format 16 bit Channels min: 2 Channels max: 2 Rate min: 44100 Rate max: 48000 Periods min: 1 Periods max: 32 Period Size: 2048 Get periods: 4 ;-) - and which symbol is used: (gdb) bt #0 __snd_pcm_hw_params_get_channels_max (params=0x10017f68, val=0x7fffe48c) at pcm.c:3334 #1 0x10003cac in GSMP::ALSAPCM::GetChannelsMax() (this=0x74e0) at ALSAHelper.cc:342 #2 0x10001c00 in main () at ALSAHelper.cc:67 Any idea what is happening to ALSA's symbol versioning using shared objects? In the case it matters, this is all on PowerPC (ROCK Linux) ... gcc (GCC) 3.2.3 GNU C Library stable release version 2.3.2, by Roland McGrath et al. GNU ld version 2.14.90.0.4.1 20030523 GNU assembler 2.14.90.0.4.1 20030523 Thanks in advance - yours, René -- René Rebe - Europe/Germany/Berlin [EMAIL PROTECTED] [EMAIL PROTECTED] http://www.rocklinux.org http://www.rocklinux-consulting.de http://gsmp.tfh-berlin.de/gsmp http://gsmp.tfh-berlin.de/rene --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Problem with __OLD_GET
Hi, Takashi I have no experience with libtool myself, but from what I can see the plugin host (beep-media-player) uses it. libtool --version tells me this: ltmain.sh (GNU libtool) 1.4.3 (1.922.2.111 2002/10/23 02:54:36). But at the same time we have another person, Rene Rebe, posting about a similar problem and who does not appear to be using libtool (correct me here if I'm mistaken). Regards Arve Knudsen On Fri, 16 Jan 2004 19:57:23 +0100, Takashi Iwai [EMAIL PROTECTED] wrote: At Thu, 15 Jan 2004 15:23:06 +0100, Arve Knudsen wrote: Hi Like I explained in a post some time back, I've been having problems with not getting correct values from snd_pcm_hw_params functions (specifically snd_pcm_hw_params_get_channels_max). I never got an answer though, and the problem disappeared for a while. However it has reappeared, so I decided to find the source (no pun intended) of the problem. It turns out for some reason the deprecated symbols are getting called (__OLD_GET), so when I expect to have the passed value pointer filled in, all that happens is it gets zeroed. I'm afraid I don't understand all the preprocessor magic, so I don't completely understand why this happens. That is, the correct versions of these functions have been called correctly, but suddenly the old ones are used instead. Maybe its down to some weird linking problem, it only happens with a dynamically loaded PortAudio plugin I've written for an xmms fork called beep-media-player. If anyone could come up with a likely explanation as to what's going on here, I'd be grateful. Is there some mechanism that figures my lib is linked against an old version of ALSA-lib? Btw, I'm using ALSA-lib 1.0.1, and drivers compiled into 2.6.1-mm2. is libtool enough new? otherwise this kind of confusion can happen. Takashi --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel --- The SF.Net email is sponsored by EclipseCon 2004 Premiere Conference on Open Tools Development and Integration See the breadth of Eclipse activity. February 3-5 in Anaheim, CA. http://www.eclipsecon.org/osdn ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Problem with __OLD_GET
Hi Like I explained in a post some time back, I've been having problems with not getting correct values from snd_pcm_hw_params functions (specifically snd_pcm_hw_params_get_channels_max). I never got an answer though, and the problem disappeared for a while. However it has reappeared, so I decided to find the source (no pun intended) of the problem. It turns out for some reason the deprecated symbols are getting called (__OLD_GET), so when I expect to have the passed value pointer filled in, all that happens is it gets zeroed. I'm afraid I don't understand all the preprocessor magic, so I don't completely understand why this happens. That is, the correct versions of these functions have been called correctly, but suddenly the old ones are used instead. Maybe its down to some weird linking problem, it only happens with a dynamically loaded PortAudio plugin I've written for an xmms fork called beep-media-player. If anyone could come up with a likely explanation as to what's going on here, I'd be grateful. Is there some mechanism that figures my lib is linked against an old version of ALSA-lib? Btw, I'm using ALSA-lib 1.0.1, and drivers compiled into 2.6.1-mm2. Thanks Arve Knudsen --- 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] nForce2 (intel8x0) playback doesn't accept 44khz
Hello Has the intel8x0 driver been made accept only 48khz for playback? I always used 44.1, and wouldn't mind continuing to do so. Also, it really baffled me at first that it would accept 44.1 for capture, but not playback. Would someone care to explain, if this is how its meant to work? Thanks Arve Knudsen --- 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] nForce2 (intel8x0) playback doesn't accept 44khz
On Wed, 14 Jan 2004 14:43:03 +0100, Takashi Iwai [EMAIL PROTECTED] wrote: At Wed, 14 Jan 2004 13:27:25 +0100, Arve Knudsen wrote: I'm sorry i wasn't being more specific, but from browsing the archive (http://www.mail-archive.com/[EMAIL PROTECTED]/msg10257.html) no, it was a bug. I got the impression the rate of intel8x0 has been recently fixed at 48khz? Anyway, this is an Asus A7N8X Deluxe with nForce2 SoundStorm onboard audio. ALSA-lib is v1.0.1, while ALSA-driver is compiled into kernel 2.6.1-mm2 (v1.0.1?). The problem is consistent across programs it seems, specifically my own code and aplay (sets rate to 48000 if I open hw). as mentioned, the support sample rate is dependent on AC97 codec. check /proc/asound/card0/codec97#0/* files. if your codec supports VRA, you'll see it in the extended id line. Takashi The thing is it used to support 44.1 just fine, its only recently there's been a problem. Besides isn't it weird that capture will support 44.1 while playback doesn't? Anyhow, the extended id line indicates it supports VRA: Extended ID : codec=0 rev=1 LDAC SDAC CDAC DSA=0 SPDIF DRA VRA Regards Arve Knudsen --- 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] nForce2 (intel8x0) playback doesn't accept 44khz
/proc/asound/card0/codec97#0/ac97#0-0: 0-0/0: Realtek ALC650 rev 2 Capabilities : DAC resolution : 20-bit ADC resolution : 18-bit 3D enhancement : Realtek 3D Stereo Enhancement Current setup Mic gain : +0dB [+0dB] POP path : pre 3D Sim. stereo : off 3D enhancement : off Loudness : off Mono output : MIX Mic select : Mic1 ADC/DAC loopback : off Extended ID : codec=0 rev=1 LDAC SDAC CDAC DSA=0 SPDIF DRA VRA Extended status : SPCV LDAC SDAC CDAC SPDIF=3/4 VRA PCM front DAC: 48000Hz PCM Surr DAC : 48000Hz PCM LFE DAC : 48000Hz PCM ADC : 22050Hz SPDIF Control: Consumer PCM Category=0x2 Generation=1 Rate=48kHz SPDIF In Status : Not Locked /proc/asound/card0/codec97#0/ac97#0-0+regs 0:00 = 5980 0:02 = 0505 0:04 = 0:06 = 0003 0:08 = 0:0a = 801e 0:0c = 801f 0:0e = 801f 0:10 = 9f1f 0:12 = 9f1f 0:14 = 9f1f 0:16 = 9f1f 0:18 = 0808 0:1a = 0:1c = 0:1e = 0:20 = 0:22 = 0:24 = 0:26 = 000f 0:28 = 05c7 0:2a = 05c1 0:2c = bb80 0:2e = bb80 0:30 = bb80 0:32 = 5622 0:34 = 0:36 = 9f80 0:38 = 9f9f 0:3a = 2824 0:3c = 0:3e = 0:40 = 0:42 = 0:44 = 0:46 = 0:48 = 0:4a = 0:4c = 0:4e = 0:50 = 0:52 = 0:54 = 0:56 = 0:58 = 0:5a = 0:5c = 0:5e = 0:60 = 0:62 = 0:64 = 0808 0:66 = 0808 0:68 = 0:6a = 0:6c = 0:6e = 0014 0:70 = 0211 0:72 = 00a0 0:74 = 0043 0:76 = 0:78 = 8003 0:7a = 57c3 0:7c = 414c 0:7e = 4720 On Wed, 14 Jan 2004 15:02:44 +0100, Takashi Iwai [EMAIL PROTECTED] wrote: At Wed, 14 Jan 2004 14:57:03 +0100, Arve Knudsen wrote: On Wed, 14 Jan 2004 14:43:03 +0100, Takashi Iwai [EMAIL PROTECTED] wrote: At Wed, 14 Jan 2004 13:27:25 +0100, Arve Knudsen wrote: I'm sorry i wasn't being more specific, but from browsing the archive (http://www.mail-archive.com/[EMAIL PROTECTED]/msg10257.html) no, it was a bug. I got the impression the rate of intel8x0 has been recently fixed at 48khz? Anyway, this is an Asus A7N8X Deluxe with nForce2 SoundStorm onboard audio. ALSA-lib is v1.0.1, while ALSA-driver is compiled into kernel 2.6.1-mm2 (v1.0.1?). The problem is consistent across programs it seems, specifically my own code and aplay (sets rate to 48000 if I open hw). as mentioned, the support sample rate is dependent on AC97 codec. check /proc/asound/card0/codec97#0/* files. if your codec supports VRA, you'll see it in the extended id line. Takashi The thing is it used to support 44.1 just fine, its only recently there's been a problem. Besides isn't it weird that capture will support 44.1 while playback doesn't? Anyhow, the extended id line indicates it supports VRA: Extended ID : codec=0 rev=1 LDAC SDAC CDAC DSA=0 SPDIF DRA VRA please show the whole entries (of all files) for debugging... Takashi --- 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: weird thing: sound will skip sometimes with OSS in xmms but not if I use esound
It could have to do with how the particular output plugin is written, or the (in my opinion) somewhat retarded plugin model of xmms with sleeps between writes to output. Regards Arve Knudsen On Thu, 08 Jan 2004 15:47:13 +0100, Måns Rullgård [EMAIL PROTECTED] wrote: Kristof vansant [EMAIL PROTECTED] writes: Does esound do something special to keep sound stable? It happens with snd-via82xx + OSS emulation. I'd rather think xmms does something that causes skips. I've seen it with a cmi8738. It's one of the reasons I stopped using xmms. It's actually quite simple to play sound without skips. --- 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] Which API to use for simple clients?
On Mon, 05 Jan 2004 09:26:21 +, Nick Ing-Simmons [EMAIL PROTECTED] wrote: Arve Knudsen [EMAIL PROTECTED] writes: patest_write_sine produces a noise but it isn't a sine wave (by ear there are some sharp edges in the waveform). That is the potential killer ... remember one advantage of portaudio was the option to use a write() interface... The blocking interface is fully implemented with the ALSA implementation, and I use it daily. It would seem there are problems with the OSS one, but its development branch after all :) patest_sine_formats hangs apparently forever. Sounds weird. Works perfectly with my setup. Can you tell me which one of the underlying host APIs (JACK/OSS/ALSA) is being used? Can you tell me how to tell? You can use something like this to print the API name: printf(Host API: %s\n, Pa_GetHostApiInfo(Pa_GetDefaultHostApi())-name); Unless I explicitly disable it, OSS shows up as default. I just tested the OSS implementation for the first time, and it behaves as you describe. I cannot help you with OSS or JACK I'm afraid, as I concentrate on the ALSA bit. I don't know what the current state of OSS and JACK support is, but I don't think they've been as regularly updated as the ALSA one. My recommendation, for now, would be to configure PortAudio to compile with only ALSA support. Then the ALSA host API should be used by default, and things should work better I think. Worse: 1019 make clean 1020 make distclean 1021 rm config.cache 1022 rm config.status 1023 ./configure --without-jack --without-oss 1024 make 1025 bin/patest_sine_formats [EMAIL PROTECTED]:~/portaudio !1025 bin/patest_sine_formats PortAudio Test: output Signed 16 Bit An error occured while using the portaudio stream Error number: -9997 Error message: Invalid sample rate My ALSA card is quite capable of doing 44100 Can you verify that the ALSA API is in use, after configuring out OSS and JACK? I cannot see why this test should fail, granted your card supports the given samplerate. If you could be bothered, perhaps you could add some debug output to function SetApproximateSampleRate at pa_linux_alsa/pa_linux_alsa.c: 1575? Ie. you could verify that the correct samplerate is indeed passed to ALSA-lib, and that ALSA-lib rejects it. This is using a v19 snapshot: -rw-rw-r--1 nick users 486933 2004-01-04 11:25 /home/nick/tgzs/pa_snapshot_v19.tar.gz Time/date are GMT. Adding jack back in makes no difference. Adding oss back in gives same fail. So it seems that it is using oss and it is broken, can't say I am surprised - if you recall the original message was prompted as I was moving to native ALSA 'cos OSS emulation was flakey. I think v19 PortAudio OSS still needs some work, I'm experiencing similar problems. Regards Arve Knudsen --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] ALSA-lib reports zero channels for devices
Hi I have a recurring problem with ALSA-lib that _seems_ linked to the 1.0 release candidates. With one certain application (I've written a dynamically loaded PortAudio plugin for a mediaplayer), ALSA-lib will report maximum zero capture and playback channels for both my devices (nVidia nForce2 and RME DIGI9636). When running minimal PortAudio programs capabilities are reported correctly. I've managed to fix this in the past by reinstalling 0.9.8, but 1.0rc2 has worked for a while without problems. Today the same thing happened though, consistently zero available channels would be reported, with this one app (using a PortAudio output plugin). So I reinstalled 0.9.8, and rebooted. The problem was still there the first time I ran the app after reboot (with 0.9.8 installed) though, the second time it was gone. Weird, huh? I'm using the ALSA-driver version compiled into the 2.6.1-rc1-mm1 kernel, which version is this, 1.0rc*? Could there be a version incompatibility between driver and lib? I don't think there's anything special to the way I open and query the card, I simply do a snd_pcm_open followed by a snd_pcm_nonblock (the open mode could be nonblocking), followed by snd_pcm_hw_params_any and then snd_pcm_hw_params_get_channels_max. Has anyone experienced similar behaviour? Thanks in advance Arve Knudsen --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Which API to use for simple clients?
On Mon, 05 Jan 2004 13:36:33 +, [EMAIL PROTECTED] wrote: patest_sine_formats hangs apparently forever. Sounds weird. Works perfectly with my setup. Can you tell me which one of the underlying host APIs (JACK/OSS/ALSA) is being used? Can you tell me how to tell? You can use something like this to print the API name: printf(Host API: %s\n, Pa_GetHostApiInfo(Pa_GetDefaultHostApi())-name); Unless I explicitly disable it, OSS shows up as default. That segfaulted 1st place I put it. Putting it after the open works Oh yeah, sorry, I forgot to mention it has to come after the Pa_Initialize call. My bad :| [EMAIL PROTECTED]:~/portaudio !1025 bin/patest_sine_formats PortAudio Test: output Signed 16 Bit An error occured while using the portaudio stream Error number: -9997 Error message: Invalid sample rate My ALSA card is quite capable of doing 44100 Can you verify that the ALSA API is in use, after configuring out OSS and JACK? I cannot see why this test should fail, granted your card supports the given samplerate. If you could be bothered, perhaps you could add some debug output to function SetApproximateSampleRate at pa_linux_alsa/pa_linux_alsa.c: 1575? Ie. you could verify that the correct samplerate is indeed passed to ALSA-lib, and that ALSA-lib rejects it. SetApproximateSampleRate is @ line 1583 in my copy: Making that : err = snd_pcm_hw_params_set_rate( pcm, hwParams, approx, dir ); printf(%s approx=%lu rate=%d dir=%d\n, __FUNCTION__,approx, err, dir); return err; Yields: [EMAIL PROTECTED]:~/portaudio bin/patest_sine_formats PortAudio Test: output Signed 16 Bit SetApproximateSampleRate approx=44100 rate=-22 dir=0 Host API: ALSA An error occured while using the portaudio stream Error number: -9997 Error message: Invalid sample rate [EMAIL PROTECTED]:~/portaudio Which seems sane. Changing it to: err = snd_pcm_hw_params_set_rate_near( pcm, hwParams, approx, dir ); printf(%s approx=%lu rate=%d dir=%d\n, __FUNCTION__,approx, err, dir); return err; Yields: [EMAIL PROTECTED]:~/portaudio bin/patest_sine_formats PortAudio Test: output Signed 16 Bit SetApproximateSampleRate approx=48000 rate=0 dir=0 Host API: ALSA Waiting 10 seconds for sound to finish. PortAudio Test Finished: Signed 16 Bit So perhaps my card does _NOT_ support 44100Hz after all. This is the card as autodetected/configured by SuSE9.0's YaST. Seems there are options to play with including the clock rate but I don't know what I am doing ... It looks like you got PortAudio working at least :) You can also look up the PaDeviceInfo struct for any device, to check out the default sample rate. I think the ALSA plughw device will convert the samplerate to a hardware supported one for you, so that might be your best bet? I have never used the PCM plugin myself, but its possible to specify a custom device string with pa_linux_alsa. If you look in the pa_linux_alsa.h file, you'll see a custom stream structure, PaAlsaStreamInfo, which basically can be used like this: PaAlsaStreamInfo alsaStreamInfo; PaStreamParameters outputParameters; PaAlsa_InitializeStreamInfo(alsaStreamInfo); alsaStreamInfo.deviceString = plughw:0,0; outputParameters.device = paUseHostApiSpecificDeviceSpecification; outputParameters.hostApiSpecificStreamInfo = alsaStreamInfo; It's device string will then be used when opening the output device. Hope this helps Arve Knudsen --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Which API to use for simple clients?
On Mon, 05 Jan 2004 13:36:33 +, [EMAIL PROTECTED] wrote: patest_sine_formats hangs apparently forever. Sounds weird. Works perfectly with my setup. Can you tell me which one of the underlying host APIs (JACK/OSS/ALSA) is being used? Can you tell me how to tell? You can use something like this to print the API name: printf(Host API: %s\n, Pa_GetHostApiInfo(Pa_GetDefaultHostApi())-name); Unless I explicitly disable it, OSS shows up as default. That segfaulted 1st place I put it. Putting it after the open works Oh yeah, sorry, I forgot to mention it has to come after the Pa_Initialize call. My bad :| [EMAIL PROTECTED]:~/portaudio !1025 bin/patest_sine_formats PortAudio Test: output Signed 16 Bit An error occured while using the portaudio stream Error number: -9997 Error message: Invalid sample rate My ALSA card is quite capable of doing 44100 Can you verify that the ALSA API is in use, after configuring out OSS and JACK? I cannot see why this test should fail, granted your card supports the given samplerate. If you could be bothered, perhaps you could add some debug output to function SetApproximateSampleRate at pa_linux_alsa/pa_linux_alsa.c: 1575? Ie. you could verify that the correct samplerate is indeed passed to ALSA-lib, and that ALSA-lib rejects it. SetApproximateSampleRate is @ line 1583 in my copy: Making that : err = snd_pcm_hw_params_set_rate( pcm, hwParams, approx, dir ); printf(%s approx=%lu rate=%d dir=%d\n, __FUNCTION__,approx, err, dir); return err; Yields: [EMAIL PROTECTED]:~/portaudio bin/patest_sine_formats PortAudio Test: output Signed 16 Bit SetApproximateSampleRate approx=44100 rate=-22 dir=0 Host API: ALSA An error occured while using the portaudio stream Error number: -9997 Error message: Invalid sample rate [EMAIL PROTECTED]:~/portaudio Which seems sane. Changing it to: err = snd_pcm_hw_params_set_rate_near( pcm, hwParams, approx, dir ); printf(%s approx=%lu rate=%d dir=%d\n, __FUNCTION__,approx, err, dir); return err; Yields: [EMAIL PROTECTED]:~/portaudio bin/patest_sine_formats PortAudio Test: output Signed 16 Bit SetApproximateSampleRate approx=48000 rate=0 dir=0 Host API: ALSA Waiting 10 seconds for sound to finish. PortAudio Test Finished: Signed 16 Bit So perhaps my card does _NOT_ support 44100Hz after all. This is the card as autodetected/configured by SuSE9.0's YaST. Seems there are options to play with including the clock rate but I don't know what I am doing ... It looks like you got PortAudio working at least :) You can also look up the PaDeviceInfo struct for any device, to check out the default sample rate. I think the ALSA plughw device will convert the samplerate to a hardware supported one for you, so that might be your best bet? I have never used the PCM plugin myself, but its possible to specify a custom device string with pa_linux_alsa. If you look in the pa_linux_alsa.h file, you'll see a custom stream structure, PaAlsaStreamInfo, which basically can be used like this: PaAlsaStreamInfo alsaStreamInfo; PaStreamParameters outputParameters; PaAlsa_InitializeStreamInfo(alsaStreamInfo); alsaStreamInfo.deviceString = plughw:0,0; outputParameters.device = paUseHostApiSpecificDeviceSpecification; outputParameters.hostApiSpecificStreamInfo = alsaStreamInfo; It's device string will then be used when opening the output device. Hope this helps Arve Knudsen --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [Alsa-devel][OT] Which API to use for simple clients?
On Mon, 05 Jan 2004 15:55:46 +, [EMAIL PROTECTED] wrote: Arve Knudsen [EMAIL PROTECTED] writes: My ALSA card is quite capable of doing 44100 Can you verify that the ALSA API is in use, after configuring out OSS and JACK? I cannot see why this test should fail, granted your card supports the given samplerate. If you could be bothered, perhaps you could add some debug output to function SetApproximateSampleRate at pa_linux_alsa/pa_linux_alsa.c: 1575? Ie. you could verify that the correct samplerate is indeed passed to ALSA-lib, and that ALSA-lib rejects it. SetApproximateSampleRate is @ line 1583 in my copy: Making that : err = snd_pcm_hw_params_set_rate( pcm, hwParams, approx, dir ); printf(%s approx=%lu rate=%d dir=%d\n, __FUNCTION__,approx, err, dir); return err; Yields: [EMAIL PROTECTED]:~/portaudio bin/patest_sine_formats PortAudio Test: output Signed 16 Bit SetApproximateSampleRate approx=44100 rate=-22 dir=0 Host API: ALSA An error occured while using the portaudio stream Error number: -9997 Error message: Invalid sample rate [EMAIL PROTECTED]:~/portaudio Which seems sane. Changing it to: err = snd_pcm_hw_params_set_rate_near( pcm, hwParams, approx, dir ); printf(%s approx=%lu rate=%d dir=%d\n, __FUNCTION__,approx, err, dir); return err; Yields: [EMAIL PROTECTED]:~/portaudio bin/patest_sine_formats PortAudio Test: output Signed 16 Bit SetApproximateSampleRate approx=48000 rate=0 dir=0 Host API: ALSA Waiting 10 seconds for sound to finish. PortAudio Test Finished: Signed 16 Bit So perhaps my card does _NOT_ support 44100Hz after all. This is the card as autodetected/configured by SuSE9.0's YaST. Seems there are options to play with including the clock rate but I don't know what I am doing ... It looks like you got PortAudio working at least :) Well if you consider 48000 near 44100 ... This doesn't have to do with PortAudio, frankly. PortAudio does not convert samplerates, it will be constrained by the host device. You can also look up the PaDeviceInfo struct for any device, to check out the default sample rate. I think the ALSA plughw device will convert the samplerate to a hardware supported one for you, so that might be your best bet? I think so - googling for 8235 and 44100 shows I am not the 1st to have this kind of problem... I have never used the PCM plugin myself, but its possible to specify a custom device string with pa_linux_alsa. If you look in the pa_linux_alsa.h file, you'll see a custom stream structure, PaAlsaStreamInfo, which basically can be used like this: PaAlsaStreamInfo alsaStreamInfo; PaStreamParameters outputParameters; PaAlsa_InitializeStreamInfo(alsaStreamInfo); alsaStreamInfo.deviceString = plughw:0,0; outputParameters.device = paUseHostApiSpecificDeviceSpecification; outputParameters.hostApiSpecificStreamInfo = alsaStreamInfo; It's device string will then be used when opening the output device. But having a custom string then means I need to know that A. PortAudio is using ALSA B. This user's ALSA hw device cannot do my rate PortAudio allows you to test a given configuration, which is not particular to ALSA. C. Which magic custom string to use. Some devices (software) are not enumerated by ALSA, so there is no way for PortAudio to know. If I need to know that much I might as well use native ALSA code... The only reason I mentioned plughw is you might want to convert from 44100 to 48000, since your hardware device doesn't support 44k. This is particular to ALSA. Regular hardware devices will be available through PortAudio, requiring no specialized knowledge. Surely the whole point of PortAudio is that app says open sound card for 44100Hz, 16-bit, 2 channels and the PortAudio layer figures out how to do that? Like I pointed out earlier, PortAudio performs no samplerate conversion (nor will it provide more or less channels than the device supports). The point, as I see it, is cross platform abstraction (with benefits such as buffer adaption and bitdepth conversion). Wether a card supports a specific configuration can be tested, or you can go with the defaults. However, certain API's have their own ways of doing things. ALSA offers software devices, such as plughw, which are not currently enumerated along with the other devices. So in order to use plughw, you will have to pass a custom device string. This requires specialized knowledge in the client app of course, but its the best solution I've come up with. This is getting entirely offtopic though, maybe we best discuss this on the PortAudio list? If you're still interested in the API that is. Regards Arve Knudsen --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click
Re: [Alsa-devel] Which API to use for simple clients?
On Sun, 04 Jan 2004 12:00:57 +, Nick Ing-Simmons [EMAIL PROTECTED] wrote: The ALSA implementation of v19 (development branch) is well developed, and fairly stable from what I can see (being one of the developers). There hasn't been a lot of feedback, but my own testing hasn't turned up any bugs in a while. I few clicks but nothing too horrible. Clicks as in audio glitches? I experience no glitches in daily use (blocking API), unless I set the buffer size too low. PortAudio also offers two different interfaces to the programmer, both blocking and callback interfaces are completed for the ALSA implementation. So you can choose whichever suits your application the best. patest_write_sine produces a noise but it isn't a sine wave (by ear there are some sharp edges in the waveform). patest_sine_formats hangs apparently forever. Sounds weird. Works perfectly with my setup. Can you tell me which one of the underlying host APIs (JACK/OSS/ALSA) is being used? I just tested the OSS implementation for the first time, and it behaves as you describe. I cannot help you with OSS or JACK I'm afraid, as I concentrate on the ALSA bit. I don't know what the current state of OSS and JACK support is, but I don't think they've been as regularly updated as the ALSA one. My recommendation, for now, would be to configure PortAudio to compile with only ALSA support. Then the ALSA host API should be used by default, and things should work better I think. At the same time, should you wish to write cross-platform programs, PortAudio supports different platforms. I don't know the current state of all the implementations, but Windows MME and ASIO should be well functional and SGI IRIX seems to be coming along. Hope this helps If nothing else it serves as example code for oss/alsa/jack setup. Will not rule it out. Appreciate the feedback Arve Knudsen --- This SF.net email is sponsored by: IBM Linux Tutorials. Become an expert in LINUX or just sharpen your skills. Sign up for IBM's Free Linux Tutorials. Learn everything from the bash shell to sys admin. Click now! http://ads.osdn.com/?ad_id78alloc_id371op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Query devices in a non-blocking fashion
On Mon, 15 Dec 2003 09:59:16 +0100 (CET), Jaroslav Kysela [EMAIL PROTECTED] wrote: On Sun, 14 Dec 2003, Arve Knudsen wrote: On Mon, 15 Dec 2003 01:17:26 +0900, Patrick Shirkey [EMAIL PROTECTED] wrote: If we have a DB of info how would we define the abilities of each device? I assume this info is available in the driver layer because there is a point where ALSA will return false eg. if a card is not able to run at 48000Hz My opinion is that a simple function could be included in alsactl which scans for available devices, makes a list of their abilities. Everyone uses post-insert alsactl restore in the modules.conf file so it would be essentially a non issue from a user perspective. Couldn't this be saved in the config settings for alsactl? This whole database thing seems like overkill to me, to be honest. This is dynamic information would best be obtained from cards during operation, the only problem is that you have to lock the device. A better design would be to, if possible, allow the configuration space to be read even when a device is streaming. I dont know the dirty details of writing drivers, but would this be a problem? Perhaps we could differ between read-locked and write-locked configuration, so there would be inclusive read access to the device, and totally exclusive access if it is to be modified. Again, the configuration space is runtime information and it might depend if a stream is active for given card. So, information might be useless (different). Again, much better is to give this information from the user space rather than adding code to the drivers. We may also describe the constraints here. Will these constraints be updated during runtime, so they take the device's current state into account, such as samplerate vs number of channels? I hope this won't add to the complexity of ALSA-lib, though. Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Query devices in a non-blocking fashion
On Mon, 15 Dec 2003 01:17:26 +0900, Patrick Shirkey [EMAIL PROTECTED] wrote: If we have a DB of info how would we define the abilities of each device? I assume this info is available in the driver layer because there is a point where ALSA will return false eg. if a card is not able to run at 48000Hz My opinion is that a simple function could be included in alsactl which scans for available devices, makes a list of their abilities. Everyone uses post-insert alsactl restore in the modules.conf file so it would be essentially a non issue from a user perspective. Couldn't this be saved in the config settings for alsactl? This whole database thing seems like overkill to me, to be honest. This is dynamic information would best be obtained from cards during operation, the only problem is that you have to lock the device. A better design would be to, if possible, allow the configuration space to be read even when a device is streaming. I dont know the dirty details of writing drivers, but would this be a problem? Perhaps we could differ between read-locked and write-locked configuration, so there would be inclusive read access to the device, and totally exclusive access if it is to be modified. Hope some of this makes sense Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Understanding JACK's inner loop?
Hi, Ryan If you're interested in the mechanics of full duplex memory-mapped i/o with ALSA-lib you could always check out PortAudio v19 CVS at www.portaudio.com, which implements both a blocking and callback interface. If you're interested specifically in JACK interfacing with ALSA-lib I would think alsa_driver.c would be the place to look. Hope this helps Arve Knudsen On Wed, 10 Dec 2003 00:38:50 -0800, Ryan Cassidy [EMAIL PROTECTED] wrote: Hello all, I am trying to understand the specifics of the mechanism that JACK uses to perform audio duplexing (simultaneous playback and capture of audio). I have downloaded the latest source from CVS. Is the file 'alsa_driver.c' a good place to start (i.e. is this where the magic happens)? Does JACK use memory-mapped read/write? Any info. greatly appreciated. Cheers, rjc. -- Ryan Cassidy Electrical Engineering Graduate Student, CCRMA Researcher Stanford University E-mail: [EMAIL PROTECTED] --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Query devices in a non-blocking fashion
On Mon, 8 Dec 2003 11:49:45 +0100, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Arve Knudsen hat gesagt: // Arve Knudsen wrote: I'm one of the developers responsible for the ALSA implementation of a cross platform audio wrapper called PortAudio (www.portaudio.com), which gathers info about available devices during startup. Which reminds me to ask: how does Portaudio currently cope with user-defined, not enumerable interfaces in ALSA? Only concrete hardware devices are considered at the moment as far as I can tell, that is, we enumerate based on snd_card_next. I'll have to admit I never really got into the ALSA configuration system. I might look into it later, once I'm happy with the basic functionality of the implementation (getting there). Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Re: [Alsa-devel][OT]Was: Query devices in a non-blocking fashion
On Mon, 8 Dec 2003 12:39:25 +0100, Frank Barknecht [EMAIL PROTECTED] wrote: Hallo, Arve Knudsen hat gesagt: // Arve Knudsen wrote: On Mon, 8 Dec 2003 11:49:45 +0100, Frank Barknecht [EMAIL PROTECTED] wrote: Which reminds me to ask: how does Portaudio currently cope with user-defined, not enumerable interfaces in ALSA? Only concrete hardware devices are considered at the moment as far as I can tell, that is, we enumerate based on snd_card_next. I'll have to admit I never really got into the ALSA configuration system. I might look into it later, once I'm happy with the basic functionality of the implementation (getting there). Ah, that would be cool. I'm not really intimate with PortAudio, but my main application, Pure Data (not written by me ;), is using it in parallel to direct ALSA/JACK/OSS backends. The goal is, to switch to PA fully, but it would very annoying not to be able to select ALSA devices by name. Actually from a developer's perspective, ALSA's PCM configuration system is rather simple: Just use the name (char*) the user provides where you'd otherwise use something like hw:0 or default. The only problem is, that this is not enumarable. But not providing the possibility for a user, to specify a PCM name, is like trying to outsmart the user. There is infrastructure support for custom stream info when opening a stream, so it would be possible to pass a device string through this, but it is unimplemented as of yet. Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Query devices in a non-blocking fashion
On Mon, 8 Dec 2003 16:19:36 +0100, Giuliano Pochini [EMAIL PROTECTED] wrote: On Sun, 07 Dec 2003 14:19:28 -0500 Paul Davis [EMAIL PROTECTED] wrote: i personally am heading towards believing that we made a design decision that was wrong here. i now tend to think that the PCM interface should not be involved with configuring the hardware at all, and that this should be left to the control API. when you open the PCM device, you get whatever is currently configured. if that's not what you want, you open the control API first, configure the device, then open the PCM device. i think this would be much much simpler for most application programmers (not as simple as JACK, but ...) and it would also mirror what happens in the windows world to some extent, where control applets are used to change aspects of the card config. still, its pretty much too late for that. I don't agree. The control API (usually) is for things that don't affect the way data is transferred between the card the the computer. Sample rate, format, etc. are used to configure the hardware at the driver level, but from the point of view of the application they are attributes of the substream. The application has to take them into account. It can't just open the PCM device and play/record something without knowing the format. So you'll end up always using two different APIs to do the same things you now can do with only one. Wether its done via the control or pcm interface, it'd be good to have a loose coupling between configuration and streams, so one could could access configuration space without locking a stream don't you think? I mean, with ASIO, from what I can see there is no problem obtaining info about devices in the system even if they might be in use. Shouldn't we at least aim for the same flexibility with ALSA? Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Query devices in a non-blocking fashion
I'd like to be able to query the capabilities (number of channels, buffer size etc.) of ALSA devices in the system, even if they should be in use by some other process. The only current way to probe device capabilities is to open a pcm, and use snd_pcm_hw_params, correct? At least this is my current approach, but I'd like to query the devices without first acquiring exclusive access. If there is currently no way around acquiring a device for querying, maybe this requirement could be loosened in a future version of ALSA? Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Query devices in a non-blocking fashion
On Sun, 7 Dec 2003 19:40:23 +0100 (CET), Jaroslav Kysela [EMAIL PROTECTED] wrote: On Sun, 7 Dec 2003, Arve Knudsen wrote: I'd like to be able to query the capabilities (number of channels, buffer size etc.) of ALSA devices in the system, even if they should be in use by some other process. The only current way to probe device capabilities is to open a pcm, and use snd_pcm_hw_params, correct? At least this is my current approach, but I'd like to query the devices without first acquiring exclusive access. If there is currently no way around acquiring a device for querying, maybe this requirement could be loosened in a future version of ALSA? Nope. You ask for runtime information. This information can change due various hardware contraints so we cannot give you an useful information without blocking the device. Anyway, auto-probing for devices is a bad idea. Let user to choose the device (hw:X,Y or plughw:X,Y or some abstract name in a dialog box) yourself. The hw:X,Y numbers can be determined using the control API in a non-blocking way. The user is allowed to choose between devices, but its also good to be able to display information about the different units. Like its normal in Windows audio applications to choose between available devices in the system and their respective channels. Are you saying this is a bad thing? I think that we should provide the list of devices with a description via some interface in alsa-lib. Isn't this pretty much what I'm asking for? I don't care how its done, I would just like to obtain available information in some civilized manner (so I can gather info during initialization) :) Speaking of information, I wouldn't mind some info from each driver about supported period sizes, like ASIO has a way of obtaining buffer granularity I think. Could be useful for determining a common period size if a full-duplex stream consists of two different devices. Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Query devices in a non-blocking fashion
On Sun, 07 Dec 2003 14:19:28 -0500, Paul Davis [EMAIL PROTECTED] wrote: I'd like to be able to query the capabilities (number of channels,=20 buffer size etc.) of ALSA devices in the system, even if they should be in us= e=20 by some other process. The only current way to probe device capabilities = is to open a pcm, and use snd_pcm_hw_params, correct? At least this is my current approach, but I'd like to query the devices without first acquiring exclusive access. If there is currently no way around=20 acquiring a device for querying, maybe this requirement could be loosened in a future version of ALSA? Nope. You ask for runtime information. This information can change due various hardware contraints so we cannot give you an useful information without blocking the device. Anyway, auto-probing for devices is a bad idea. Let user to choose the device (hw:X,Y or plughw:X,Y or some abstract name in a dialog box) yourself. The hw:X,Y numbers can be determined using the control API in= a non-blocking way. The user is allowed to choose between devices, but its also good to be=20 able to display information about the different units. Like its normal in= =20 Windows audio applications to choose between available devices in the=20 system and their respective channels. Are you saying this is a bad thing? its not a *bad* thing, but it is tricky to get it 100% correct. let me explain the kind of thing that is going on *at the moment*. the drivers i know best are the RME hdsp and digi9652. the number of channels one of these devices has depends on the sample rate you want to use it with. hence, its not possible to say unambigously RME HDSP (26 channels) because it might be RME HDSP (12 channels). in this particular case, you could consider this to be a detail: you should report the number of channels available at the current sample rate. ok. however, there are other similar aspects of several cards that can't be finessed as easily as this; sample format, duplex behaviour, sample rates etc. all end up being dependent on other aspects of the configuration you are asking about. i personally am heading towards believing that we made a design decision that was wrong here. i now tend to think that the PCM interface should not be involved with configuring the hardware at all, and that this should be left to the control API. when you open the PCM device, you get whatever is currently configured. if that's not what you want, you open the control API first, configure the device, then open the PCM device. i think this would be much much simpler for most application programmers (not as simple as JACK, but ...) and it would also mirror what happens in the windows world to some extent, where control applets are used to change aspects of the card config. still, its pretty much too late for that. Wow, this is somewhat along the lines of what I was thinking myself. Although it didn't manifest itself as clearly. I am aware of the Hammerfall problem, as its also somewhat painful in Windows. Logic Audio never quite coped with it, from what I remember. But there seems to be a separation between obtaining information about a card, and actually acquiring it. Perhaps this could be refined in a future design of ALSA? Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Query devices in a non-blocking fashion
On Sun, 7 Dec 2003 20:38:48 +0100 (CET), Jaroslav Kysela [EMAIL PROTECTED] wrote: On Sun, 7 Dec 2003, Arve Knudsen wrote: On Sun, 07 Dec 2003 14:19:28 -0500, Paul Davis [EMAIL PROTECTED] wrote: I'd like to be able to query the capabilities (number of channels,=20 buffer size etc.) of ALSA devices in the system, even if they should be in us= e=20 by some other process. The only current way to probe device capabilities = is to open a pcm, and use snd_pcm_hw_params, correct? At least this is my current approach, but I'd like to query the devices without first acquiring exclusive access. If there is currently no way around=20 acquiring a device for querying, maybe this requirement could be loosened in a future version of ALSA? Nope. You ask for runtime information. This information can change due various hardware contraints so we cannot give you an useful information without blocking the device. Anyway, auto-probing for devices is a bad idea. Let user to choose the device (hw:X,Y or plughw:X,Y or some abstract name in a dialog box) yourself. The hw:X,Y numbers can be determined using the control API in= a non-blocking way. The user is allowed to choose between devices, but its also good to be=20 able to display information about the different units. Like its normal in= =20 Windows audio applications to choose between available devices in the=20 system and their respective channels. Are you saying this is a bad thing? its not a *bad* thing, but it is tricky to get it 100% correct. let me explain the kind of thing that is going on *at the moment*. the drivers i know best are the RME hdsp and digi9652. the number of channels one of these devices has depends on the sample rate you want to use it with. hence, its not possible to say unambigously RME HDSP (26 channels) because it might be RME HDSP (12 channels). in this particular case, you could consider this to be a detail: you should report the number of channels available at the current sample rate. ok. however, there are other similar aspects of several cards that can't be finessed as easily as this; sample format, duplex behaviour, sample rates etc. all end up being dependent on other aspects of the configuration you are asking about. i personally am heading towards believing that we made a design decision that was wrong here. i now tend to think that the PCM interface should not be involved with configuring the hardware at all, and that this should be left to the control API. when you open the PCM device, you get whatever is currently configured. if that's not what you want, you open the control API first, configure the device, then open the PCM device. i think this would be much much simpler for most application programmers (not as simple as JACK, but ...) and it would also mirror what happens in the windows world to some extent, where control applets are used to change aspects of the card config. still, its pretty much too late for that. Wow, this is somewhat along the lines of what I was thinking myself. Although it didn't manifest itself as clearly. I am aware of the Hammerfall problem, as its also somewhat painful in Windows. Logic Audio never quite coped with it, from what I remember. But there seems to be a separation between obtaining information about a card, and actually acquiring it. Perhaps this could be refined in a future design of ALSA? We all think in the same way, but there's no simple solution for this problem. I prefer to have such configuration information in an user-space database accessed via an alsa-lib API. It's nothing for the kernel space. I dunno, I think Paul's thoughts sound sensible. Its not solved in a simple manner, but it was obviously solved somehow with other driver architectures. Will this database cope with runtime variables, such as the number of channels with RME Hammerfall though (dependent on samplerate)? Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Query devices in a non-blocking fashion
On Sun, 7 Dec 2003 21:00:13 +0100 (CET), Jaroslav Kysela [EMAIL PROTECTED] wrote: On Sun, 7 Dec 2003, Arve Knudsen wrote: We all think in the same way, but there's no simple solution for this problem. I prefer to have such configuration information in an user-space database accessed via an alsa-lib API. It's nothing for the kernel space. I dunno, I think Paul's thoughts sound sensible. Its not solved in a simple manner, but it was obviously solved somehow with other driver architectures. With very little success when a complicated hardware is in the machine. I can't remember having any real problems with this on Windows, or hearing about any such problems from others? There was the problem with Logic Audio not coping with Hammerfall's variable numberof channels, but I think other applications worked fine. Will this database cope with runtime variables, such as the number of channels with RME Hammerfall though (dependent on samplerate)? It depends on our goals and what we expect from this information. Can you describe your requirement (for what reason, you need this information?). I'm one of the developers responsible for the ALSA implementation of a cross platform audio wrapper called PortAudio (www.portaudio.com), which gathers info about available devices during startup. Also, when using this library myself, I would like to be able to display a list of devices/channels to choose from (I normally use channels 17/18). Anyway, such information is seemingly easily obtained with other driver architectures, any reason why this shouldnt be available to Linux users (disregarding the implementation issue)? Personally I see no reason to inhibit flexibility beyond what we see as immediately useful. Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Query devices in a non-blocking fashion
On Sun, 7 Dec 2003 21:44:16 +0100 (CET), Jaroslav Kysela [EMAIL PROTECTED] wrote: On Sun, 7 Dec 2003, Arve Knudsen wrote: On Sun, 7 Dec 2003 21:00:13 +0100 (CET), Jaroslav Kysela [EMAIL PROTECTED] wrote: On Sun, 7 Dec 2003, Arve Knudsen wrote: We all think in the same way, but there's no simple solution for this problem. I prefer to have such configuration information in an user-space database accessed via an alsa-lib API. It's nothing for the kernel space. I dunno, I think Paul's thoughts sound sensible. Its not solved in a simple manner, but it was obviously solved somehow with other driver architectures. With very little success when a complicated hardware is in the machine. I can't remember having any real problems with this on Windows, or hearing about any such problems from others? There was the problem with Logic Audio not coping with Hammerfall's variable numberof channels, but I think other applications worked fine. Will this database cope with runtime variables, such as the number of channels with RME Hammerfall though (dependent on samplerate)? It depends on our goals and what we expect from this information. Can you describe your requirement (for what reason, you need this information?). I'm one of the developers responsible for the ALSA implementation of a cross platform audio wrapper called PortAudio (www.portaudio.com), which gathers info about available devices during startup. Also, when using this library myself, I would like to be able to display a list of devices/channels to choose from (I normally use channels 17/18). Anyway, such information is seemingly easily obtained with other driver architectures, any reason why this shouldnt be available to Linux users (disregarding the implementation issue)? Personally I see no reason to inhibit flexibility beyond what we see as immediately useful. It depends on your look. 1) we have abstract devices not connected to hw (for example null PCM device in alsa-lib); they can support any configuration you can imagine I don't immediately see the problem, if its a software device which accepts anything, we'll treat it as that (given we are able to discern). 2) which information is valid when some devices/configurations cannot be used simultaneously? Its difficult for me to relate to this on a theoretical level, but its problematic to guard yourself against any possible issue. Anyway, wouldn't the configuration reflect this if the information is generated during runtime? That is, one opened device affects the possible configuration of another (not opened). I could be completely lost here, but I don't think we should constrain ourselves completely because of possible problems (I'd much rather look for solutions). Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Can't set 88.2/96kHz samplerate with Hammerfall
On Thu, 4 Dec 2003 09:43:36 -0800, Mark Knecht [EMAIL PROTECTED] wrote: From the Hammerfall Light Alsa sound card page: Known bugs - 96kHz and 88.2kHz not accessible via PCM interface Ok, thanks. I suppose I should've investigated a little better. Too bad, I would like to see this card working as well as under Windows. Regards Arve Knudsen Me too. I own the same card in one of my systems. This is really the downside to Linux audio. Without dedicated developers that own the cards and continue working on improvements support stalls out. The best I've been able to determine is that this card last got a real facelift over a year ago and since then nothing. I've grown to accept that it will never happen, and will be overjoyed that was if and when it finally does. Don't expect anything soon, unless you're willing to be that developer. Actually, I'm not completely opposed to the idea. But I am totally clueless when it comes to writing device drivers, and would have no idea where to start. Do you know if RME were forthcoming with specs? Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Can't set 88.2/96kHz samplerate with Hammerfall
On Thu, 04 Dec 2003 17:25:53 -0500, Paul Davis [EMAIL PROTECTED] wrote: On Thu, 4 Dec 2003 06:41:56 -0800, Mark Knecht [EMAIL PROTECTED]=20 wrote: Whenever I try to activate double speed (88.2/96kHz) mode with my RME Hammerfall Lite (DIGI 9636), snd_pcm_hw_params fails with a 'Device or resource busy' message. This is with the number of channels set to 10, since the number of ADAT channels is halved. Is this a known defect of the Hammerfall driver? Thanks Arve Knudsen From the Hammerfall Light Alsa sound card page: Known bugs - 96kHz and 88.2kHz not accessible via PCM interface Ok, thanks. I suppose I should've investigated a little better. Too bad, = I=20 would like to see this card working as well as under Windows. to be clear: you can't get DS mode using the PCM interface but you CAN (and several people have) do this, you just have to use the control interface in addition. Ah, didn't see your mail untill now. For some reason, you wind up under spam (Opera mail client filter) :\ I suppose I should investigate this possibility. Thanks Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Can't set 88.2/96kHz samplerate with Hammerfall
Hi Whenever I try to activate double speed (88.2/96kHz) mode with my RME Hammerfall Lite (DIGI 9636), snd_pcm_hw_params fails with a 'Device or resource busy' message. This is with the number of channels set to 10, since the number of ADAT channels is halved. Is this a known defect of the Hammerfall driver? Thanks Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Can't set 88.2/96kHz samplerate with Hammerfall
On Thu, 4 Dec 2003 06:41:56 -0800, Mark Knecht [EMAIL PROTECTED] wrote: Whenever I try to activate double speed (88.2/96kHz) mode with my RME Hammerfall Lite (DIGI 9636), snd_pcm_hw_params fails with a 'Device or resource busy' message. This is with the number of channels set to 10, since the number of ADAT channels is halved. Is this a known defect of the Hammerfall driver? Thanks Arve Knudsen From the Hammerfall Light Alsa sound card page: Known bugs - 96kHz and 88.2kHz not accessible via PCM interface Ok, thanks. I suppose I should've investigated a little better. Too bad, I would like to see this card working as well as under Windows. Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Broken pipe when starting pcm
Hi Whenever I turn on xrun detection, setting stop_threshold to buffer size instead of -1, snd_pcm_start refuses to work. The exit message to do with broken pipe. I figured it might be caused by an empty buffer, so I fill it with silence before start. snd_pcm_avail_update confirms this (zero frames available), but it makes no difference. This happens with both my cards, nForce2 onboard and RME DIGI9636. If someone could point out the cause of this, I'd truly appreciate it. If it matters I am running a development kernel, 2.6.0 test9-mm1. Thanks Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Broken pipe when starting pcm
On Fri, 31 Oct 2003 18:27:16 +0100, Arve Knudsen [EMAIL PROTECTED] wrote: Hi Whenever I turn on xrun detection, setting stop_threshold to buffer size instead of -1, snd_pcm_start refuses to work. The exit message to do with broken pipe. I figured it might be caused by an empty buffer, so I fill it with silence before start. snd_pcm_avail_update confirms this (zero frames available), but it makes no difference. This happens with both my cards, nForce2 onboard and RME DIGI9636. If someone could point out the cause of this, I'd truly appreciate it. If it matters I am running a development kernel, 2.6.0 test9-mm1. Thanks Arve Knudsen Ok, was able to track it down to snd_pcm_prepare. I already tested the stream state, so I knew the stream was in the prepared state before I called snd_pcm_prepare myself. However I would never have thought that calling snd_pcm_prepare before snd_pcm_start could cause problems, isnt this the standard procedure (preparing before start)? At least commenting out the prepare call before starting, makes the problem go away. I see I also have to fill the buffer before snd_pcm_start (or deal with broken pipe), I thought a silence size equal to boundary and silence threshold of 0 would cause the buffer to be automatically silenced (judging from the docs)? Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Broken pipe when starting pcm
On Sat, 01 Nov 2003 01:10:27 +0100, Arve Knudsen [EMAIL PROTECTED] wrote: On Fri, 31 Oct 2003 18:27:16 +0100, Arve Knudsen [EMAIL PROTECTED] wrote: Hi Whenever I turn on xrun detection, setting stop_threshold to buffer size instead of -1, snd_pcm_start refuses to work. The exit message to do with broken pipe. I figured it might be caused by an empty buffer, so I fill it with silence before start. snd_pcm_avail_update confirms this (zero frames available), but it makes no difference. This happens with both my cards, nForce2 onboard and RME DIGI9636. If someone could point out the cause of this, I'd truly appreciate it. If it matters I am running a development kernel, 2.6.0 test9-mm1. Thanks Arve Knudsen Ok, was able to track it down to snd_pcm_prepare. I already tested the stream state, so I knew the stream was in the prepared state before I called snd_pcm_prepare myself. However I would never have thought that calling snd_pcm_prepare before snd_pcm_start could cause problems, isnt this the standard procedure (preparing before start)? At least commenting out the prepare call before starting, makes the problem go away. I see I also have to fill the buffer before snd_pcm_start (or deal with broken pipe), I thought a silence size equal to boundary and silence threshold of 0 would cause the buffer to be automatically silenced (judging from the docs)? Awww, looks like I cheered to early. Once I compile with optimizations or try to restart because of xruns, I'm hit by the same error. Completely at a loss here, maybe I should just accept the defeat :\ Regards Arve Knudsen --- This SF.net email is sponsored by: SF.net Giveback Program. Does SourceForge.net help you be more productive? Does it help you create better code? SHARE THE LOVE, and help us help YOU! Click Here: http://sourceforge.net/donate/ ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Priming buffer
On Fri, 12 Sep 2003 16:51:26 +0200 (METDST), Clemens Ladisch [EMAIL PROTECTED] wrote: Arve Knudsen wrote: I did a little test where I set start threshold to buffer size, acquire memory using snd_pcm_mmap_begin (number of returned frames equals buffer size), fill the buffer and do a snd_pcm_mmap_commit. After the commit I check the state of the card, which is SND_PCM_STATE_PREPARED (a started pcm would be in the running state?). In theory, what you do sounds correct. (I assume you've used frames, not bytes, for the start threshold.) Maybe you want to compare your code with aplay.c, which uses start threshold, too. (It calls snd_pcm_mmap_writei, which calls snd_pcm_write_areas, which calls snd_pcm_mmap_write_areas (defined in alsa-lib/src/pcm/pcm_mmap.c), which calls snd_pcm_mmap_begin and snd_pcm_mmap_commit. Back to my original goal: I did an explicit start of the pcm after filling the buffer, but the output still sounds muted for some reason. If I start the pcm *before* writing to the buffer however (like I normally would), the output is like expected. Any idea what causes this initial muting of the output? In theory, starting the pcm with an empty buffer causes an underrun to occur immediately. If I understand you correctly, the first buffer of audio data is replaced by silence. Maybe you've set a silence threshold? Maybe I should rephrase my question, now that I've got some time to think about it. Exactly what gets started when the start threshold is reached, the transfer of frames to the audio card (assuming we're writing frames)? Obviously it doesn't affect the state of the pcm, like snd_pcm_start does (SND_PCM_STATE_RUNNING). Basically, before I've just used 0 as the start threshold and filled the buffer with zeros prior to starting the pcm. It seems to me a start threshold equal to buffer size would mean no transfer of data goes on before the buffer is filled? If this is correct, what would it mean in the case of capture (reading frames from the card). Again thanks Arve Knudsen --- 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] Priming buffer
On Thu, 11 Sep 2003 14:17:59 +0200 (METDST), Clemens Ladisch [EMAIL PROTECTED] wrote: Arve Knudsen wrote: What's the purpose of set_start_threshold? The stream will automatically start when the buffer has been filled up to the amount specified by start_threshold. Ok, obviously there's something I don't understand (no surprise). I did a little test where I set start threshold to buffer size, acquire memory using snd_pcm_mmap_begin (number of returned frames equals buffer size), fill the buffer and do a snd_pcm_mmap_commit. After the commit I check the state of the card, which is SND_PCM_STATE_PREPARED (a started pcm would be in the running state?). Or do you mean actual transfer of data, by start of stream? Back to my original goal: I did an explicit start of the pcm after filling the buffer, but the output still sounds muted for some reason. If I start the pcm *before* writing to the buffer however (like I normally would), the output is like expected. Any idea what causes this initial muting of the output? Thanks Arve Knudsen --- 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] Priming buffer
Hello I'm trying to implement a function where a client function can be called to fill a playback pcm's buffer, before it is started. It doesn't quite work as I expected though, the transient sounds muted. On the other hand, unless I fill the buffers before hand (normally with zeros), I get a burst of noise. But anyway, maybe my goal can be accomplished with the help of ALSA-lib? I've taken a good look at the sw_params interface, but I don't quite understand the intention of some of the functions even after browsing the docs. What's the purpose of set_start_threshold? Will a start threshold equivalent to buffer size mean the pcm is not actually started before the buffer is full, even after snd_pcm_start has been called (so that the buffer is in effect primed)? Sorry for bothering you guys about the seemingly obvious, but the documentation _is_ a bit brief regarding certain things. Thanks Arve Knudsen --- 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] Safe to call snd_pcm_close after failed snd_pcm_open?
Hi Is it safe to call snd_pcm_close for a pcm which failed to open (assuming the pcm handle is !NULL)? Not that important, but it might simplify my code somewhat. Regards Arve Knudsen --- 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] hw_params and approximate values
On Fri, 22 Aug 2003 15:11:08 +0200 (CEST), Jaroslav Kysela [EMAIL PROTECTED] wrote: On Thu, 21 Aug 2003, Arve Knudsen wrote: Hi I'm not sure if I quite understand the alsa-lib docs regarding the snd_pcm_hw_params API; in addition to an approximate integer value, one might specify a direction. Is the direction parameter a way to instruct ALSA to look for a floating point value in either direction? If that's the case, couldn't this be handled with floats directly? The direction means: 0 = use exactly equal number -1 = use the most close previous number 1 = use the most close next number You may also get most close value using the *_near() function. In this case, the direction selection is left on the library or driver code. Regarding floats, we cannot use floats in a simple way in kernel so it's better to avoid this requirement. By most close, do you mean the nearest supported integer value, or floating point value? The terminology is a little unclear to me, but the existance of a set_integer method leads me to believe the latter is correct. I was meaning to use set_rate_near() to find me a suitable default samplerate, but if it returns an approximate (floating point) value, I would like to be able to report the exact value. The code is meant to hide implementation details across platforms, so I cannot expose ALSA-specifics such as sub-unit direction. Thanks Arve Knudsen --- 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] hw_params and approximate values
Hi I'm not sure if I quite understand the alsa-lib docs regarding the snd_pcm_hw_params API; in addition to an approximate integer value, one might specify a direction. Is the direction parameter a way to instruct ALSA to look for a floating point value in either direction? If that's the case, couldn't this be handled with floats directly? Regards Arve Knudsen --- This SF.net email is sponsored by: VM Ware With VMware you can run multiple operating systems on a single machine. WITHOUT REBOOTING! Mix Linux / Windows / Novell virtual machines at the same time. Free trial click here:http://www.vmware.com/wl/offer/358/0 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
