Re: [Alsa-devel] EMU10K1 and the extra voice
On Sun, Jun 06, 2004 at 12:40:31PM +0200, Jaroslav Kysela wrote: Any relationship to the fact that I can only allocate 21 subdevices with ALSA, but 31 with DirectSound? Yes, 64 / 3 = 21 . That stinks (but if it's necessary for decent latency, which it doesn't get in Windows, oh well). Shouldn't the driver report 21 substreams instead of 32, though? -- Glenn Maynard --- This SF.Net email is sponsored by the new InstallShield X. From Windows to Linux, servers to mobile, InstallShield X is the one installation-authoring solution that does it all. Learn more and evaluate today! http://www.installshield.com/Dev2Dev/0504 ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] EMU10K1 and the extra voice
On Sat, Jun 05, 2004 at 12:59:36PM +, Chris Purnell wrote:
For PCM playback the EMU10K1 driver is allocating an extra voice.
This is somewhat wastefull and I kind of need all 64 voices.
Is appears to be using it to generate the period interrupts.
Does anyone know what it would take to rewrite the driver to
not need this extra voice?
Any relationship to the fact that I can only allocate 21 subdevices with ALSA,
but 31 with DirectSound?
ALSA: Advanced Linux Sound Architecture Driver Version 1.0.4rc2 (Tue Mar 30 08:19:30
2004 UTC).
ALSA Driver: 0: Sound Blaster Live! [Live], device 0: emu10k1 [EMU10K1], 32/32
subdevices avail
ALSA Driver: 0: Sound Blaster Live! [Live], device 3: emu10k1 [EMU10K1 FX8010], 8/8
subdevices avail
ALSA: dsnd_pcm_hw_params: Cannot allocate memory
ALSA: Got 21 hardware buffers
vs
DirectSound Driver: SB Live! Audio [FF80] (ctaud2k.sys)
ID: {bd6dd71a-3deb-11d1-1252b90}
DirectSound sample rates: 4000..191999 (continuous)
Got 31 hardware buffers
--
Glenn Maynard
---
This SF.Net email is sponsored by the new InstallShield X.
From Windows to Linux, servers to mobile, InstallShield X is the one
installation-authoring solution that does it all. Learn more and
evaluate today! http://www.installshield.com/Dev2Dev/0504
___
Alsa-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Improving wine support for alsa.
On Fri, May 07, 2004 at 12:30:00AM +0200, Arve Knudsen wrote: 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. It looks like SND_PCM_ASYNC isn't used, and SIGIO is never handled; instead, it just poll()s. Kernel people: is poll() less effective than using SND_PCM_ASYNC and a signal handler for low-latency sound? I'm guessing it is, but there isn't much documentation for doing low-latency sound in ALSA, or about the Linux kernel's treatment of SIGIO. (I'd expect that SIGIO would be triggered from an interrupt, but poll() wouldn't wake up as quickly, but I'm not sure.) -- Glenn Maynard --- 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] Improving wine support for alsa.
On Thu, May 06, 2004 at 09:49:31PM -0400, Paul Davis wrote: at the risk of endlessly repeating myself, If you're being asked this frequently, I'd recommend adding some notes to the documentation, recommending using poll() and not SND_PCM_ASYNC, and offering a brief explanation like this one. SIGIO is basically useless. your handler executes in signal-handling context, and can do very, very little. not even all system calls are legal in this context. SIGIO is basically a poor man's thread system, and not much more. Practical use aside, isn't that common conditions for a sound callback (which under some architectures, as I understand it, are called from an interrupt)? By the way, do you have a reference to system calls which are not legal from a signal handler in Linux? I've never seen things not work in a signal handler, even when writing a crash handler that forks a child (to output crash info in a clean environment) and at one point even did some ptracing of other threads, all from a SIGSEGV handler. -- Glenn Maynard --- 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] [PATCH] fixes warning of missing initializers for *.poll_revents
On Mon, Apr 19, 2004 at 10:26:38PM +0200, Martin Langer wrote: This bunch of patches fixes compiler warnings like these one: pcm_multi.c:646: warning: missing initializer pcm_multi.c:646: warning: (near initialization for snd_pcm_multi_ops.poll_revpcm_shm.c:589: warning: missing initializer for snd_pcm_multi_ops.poll_revents') But perhaps more interesting values than NULL are prefered Please review before applying it. gcc 2.95.4 and 3.0.4ive this warning, but 3.2.3 and 3.3.3 do not (with -Wall -W, at least). I think a large point of using this C99 syntax is to only initialize what you want, and not clutter the code with lots of redundant NULL initialization. -- Glenn Maynard --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Detecting runtime ALSA library version
I can't find any way to detect the running ALSA version, for diagnostic purposes. It can't be derived from the library name, which doesn't seem to change (it's always libasound.so.2.0.0 here, which has no relation to the actual version). It's frustrating to receive bug reports like https://sourceforge.net/tracker/?func=detailatid=421366aid=930335group_id=37892 https://sourceforge.net/tracker/download.php?group_id=37892atid=421366file_id=82701aid=930335 and not being able to tell what version of alsa-lib is in use. I'd recommend an entry point eg. const char *snd_lib_version() to get this information. As an aside: is it safe to assume that if /proc/asound/ doesn't exist, ALSA is not in use? It'd be useful to short circuit ALSA initialization for OSS people, since they often have old, broken versions of alsa-lib installed. (I know that the converse isn't true--it's possible to load the basic snd module, not load anything else, and then load OSS modules, resulting in a working OSS environment but /proc/asound/ existing.) -- Glenn Maynard --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Detecting runtime ALSA library version
On Tue, Apr 06, 2004 at 11:16:17PM +0100, James Courtier-Dutton wrote: cat /usr/include/alsa/version.h tells you the currently installed version. Nope. That only works if the development files are installed; on user systems, they usually aren't. I can't simply #include it; that'll tell me what version of ALSA was installed by the person that built the binary (which is usually not the same person), and won't follow dynamic library upgrades. Also, even if ALSA development files are installed, there's always a chance there's a mismatch; for example, there may be one version of ALSA in /usr/lib and another in /usr/local/lib. I want to know what real version of libasound.so the application is linked against, without having to worry about user error or unusual configurations resulting in incorrect output. This is why many libraries export a function to return the version in use: png_access_version_number, png_get_libpng_ver, zlibVersion(), SDL_Linked_Version(), confstr(_CS_GNU_LIBC_VERSION), and so on. -- Glenn Maynard --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] [PATCH] fixes Re: problem compiling alsa-lib CVS.
On Thu, Apr 01, 2004 at 12:57:35PM +0100, James Courtier-Dutton wrote: It's better to put this information to configure.in? No, because it selects which version of aclocal etc. that are used, which is before configure.in is even looked at. I would recommend additionally using AC_PREREQ(2.53), which is the standard way of specifying a minimum version of autoconf. (I don't know if there are similar macros for libtool and automake.) -- Glenn Maynard --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] problems using select() on alsa pcm.
On Thu, Mar 25, 2004 at 03:00:58PM +0100, Takashi Iwai wrote: Why is select deprecated? because select is just a wrapper of poll in fact (on linux)? So? There are a few other operating systems out there, and select() is very portable. (select isn't deprecated; it's simply not Linus's API to deprecate. :) -- Glenn Maynard --- This SF.Net email is sponsored by: IBM Linux Tutorials Free Linux tutorial presented by Daniel Robbins, President and CEO of GenToo technologies. Learn everything from fundamentals to system administration.http://ads.osdn.com/?ad_id=1470alloc_id=3638op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] Re: emu10k1 polishing?
On Thu, Feb 12, 2004 at 10:45:46AM +0200, Juhana Sadeharju wrote: I dislike patches, but I include one below if you insist. You dislike patches? It's the standard way that just about everyone in the free software world uses to show changes. Please get used to them. :) -- Glenn Maynard --- SF.Net is sponsored by: Speed Start Your Linux Apps Now. Build and deploy apps Web services for Linux with a free DVD software kit from IBM. Click Now! http://ads.osdn.com/?ad_id=1356alloc_id=3438op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [PATCH] Fixes: Re: [Alsa-devel] intel8x0 has stopped working.
On Thu, Feb 05, 2004 at 12:01:28PM +0100, Jaroslav Kysela wrote: My point is, I don't think setting start_threshold to buffer_size is even wrong at all. Some people might want the buffer to be full before it starts, and my patch allows for that. It's not wrong semantics. I see - it's logical, but I don't want to follow some rule as some API designers does - control magically some things. I want that developer which uses our API knows what the library / driver exactly does. We have clear conditions when the stream is started. That's it. If this isn't guaranteed to work, I'd suggest making it never work. Otherwise, programs will work on some hardware and not others, which is a case that should be minimized as much as possible; it's these kinds of subtle differences that make it very hard to write reliable (sound, video, etc) code. I've had to play games with setting hardware settings: always set the sample rate even if I don't care, use a 32k buffer size and not a 4k or 8k one--in order to make it work on as many systems as possible without failing mysteriously or triggering alsa-lib asserts. (I don't quite understand why start_threashold == buffer_size doessn't mean start when the buffer is full, though.) -- Glenn Maynard --- 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: [PATCH] Fixes: Re: [Alsa-devel] intel8x0 has stopped working.
On Thu, Feb 05, 2004 at 08:38:23PM +0100, Jaroslav Kysela wrote: Otherwise, programs will work on some hardware and not others, which is a case that should be minimized as much as possible; it's these kinds of subtle differences that make it very hard to write reliable (sound, video, etc) code. I've had to play games with setting hardware settings: always set the sample rate even if I don't care, use a 32k buffer size and not a 4k or 8k one--in order to make it work on as many systems as possible without failing mysteriously or triggering alsa-lib asserts. Send us bug-reports if you have problems. We have not a magic ball. Sample rate issue: Subject: pcm_plug.c:882: snd_pcm_plug_hw_params: Assertion `err = 0' failed. Message-ID: [EMAIL PROTECTED] Buffer size issue: Subject: CS46xx oddness Message-ID: [EMAIL PROTECTED] In retrospect, the CS46xx issue looks just like a symptom of this problem: the buffer fills up and never starts. (I'm not setting start_threshold at all, and regardless of the buffer size I only write up to 4k ahead.) I don't have this card to actually test with, though. Because we have the avail_min threshold which says that we don't want to write new data when buffer can accept less samples than this threshold. So if start_threshold is greather than '(buffer_size / avail_min) * avail_min' expression, then stream won't be automatically started, because we cannot fill data in read/write operations to satisfy the requirement that start_threshold == buffer_size. Isn't this clear and right? I don't know if avail_min is forced by hardware, but xfer_align (Takashi's explanation) is. It's easy for a program written on a system with a small xfer_align to mysteriously not work on a system with a large xfer_align, resulting in bug reports like sound doesn't play. Reporting an error in cases where sound would never start is helpful. -- Glenn Maynard --- 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: [COMPLAIN] a patched 1.0.2 has been silently reuploaded (was: [Alsa-devel] 1.0.2 release)
On Wed, Jan 28, 2004 at 02:42:30PM +0100, Thierry Vignaud wrote: we only found it because some user complained that cooker alsa-lib-1.0.2 package was broken whereas downloaded tarball from ftp.alsa-project.org wasn't. people should at least be warned about the reupload. This should go without saying. I don't want to have to spend time explaining to users that their 1.0.2 isn't *really* the latest release, much less the confusion of not being able to tell from the version what version it really is (confusion of that nature in other code has, in the past, stolen many hours of my time at a stretch). Message-ID: [EMAIL PROTECTED] I'm recreating the alsa-lib package right now. -- Glenn Maynard --- 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] Lynx AES16 driver
On Tue, Jan 20, 2004 at 09:40:36AM +0100, Giuliano Pochini wrote: Yep :( They don't like the invasive GPL. I can't understand those people. We are speaking about a *driver*. The card is the product they sell. Customers don't buy the card because they need to use the driver. Huh? I don't know about you, but certainly won't buy a card if I can't get drivers for it. -- Glenn Maynard --- 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] ALSA release 1.0.1
On Thu, Jan 08, 2004 at 07:15:10PM +0100, Jaroslav Kysela wrote: * alsa-driver CC [M] /home/glenn/alsa-driver-1.0.1/usb/usbaudio.o /home/glenn/alsa-driver-1.0.1/usb/usbaudio.c: In function `snd_usb_find_csint_desc': /home/glenn/alsa-driver-1.0.1/usb/usbaudio.c:1755: error: `USB_DT_CS_INTERFACE' undeclared (first use in this function) /home/glenn/alsa-driver-1.0.1/usb/usbaudio.c:1755: error: (Each undeclared identifier is reported only once /home/glenn/alsa-driver-1.0.1/usb/usbaudio.c:1755: error: for each function it appears in.) /home/glenn/alsa-driver-1.0.1/usb/usbaudio.c: In function `parse_audio_endpoints': /home/glenn/alsa-driver-1.0.1/usb/usbaudio.c:2341: error: `USB_DT_CS_ENDPOINT' undeclared (first use in this function) make[2]: *** [/home/glenn/alsa-driver-1.0.1/usb/usbaudio.o] Error 1 make[1]: *** [/home/glenn/alsa-driver-1.0.1/usb] Error 2 linux-2.6.0/sound/usb/usbaudio.h defines these, but alsa-driver-1.0.1/alsa-kernel/usb/usbaudio.h does not. Copying in the kernel header fixed it. * alsa-lib I'm still getting snd_pcm_plug_hw_params: Assertion `err = 0' failed. from a couple weeks ago. I can work around it, but I'm also working around other things (such as that CS46xx chip that doesn't work with 4k or 8k buffers), and the result starts to be brittle ... -- Glenn Maynard --- 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] ALSA API
On Sun, Jan 04, 2004 at 09:19:16AM -0800, Alex Lau wrote: I try to run the minimal playback program from the tutorial found in the alsa web site, snd_pcm_t *handle; char *device = hw:0,0; Shouldn't the tutorial be using default, if that's what programs that don't care should be using? (The arguments used in tutorials are what most applications are going to use.) -- Glenn Maynard --- 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_id=1278alloc_id=3371op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] ALSA API
On Sun, Jan 04, 2004 at 05:44:38PM -0800, Alex Lau wrote: I try to pass the string default to the function, but still get an error -2 (No such file or directory) Are you sure you've tested an existing ALSA application, to make sure your installation even works? (That tends to happen if /dev/snd/* doesn't exist.) -- Glenn Maynard --- 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_id=1278alloc_id=3371op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
Re: [Alsa-devel] pcm_plug.c:882: snd_pcm_plug_hw_params: Assertion `err = 0' failed.
On Tue, Dec 23, 2003 at 07:32:00PM -0500, Glenn Maynard wrote: The attached program results in: ./a.out a.out: pcm_plug.c:882: snd_pcm_plug_hw_params: Assertion `err = 0' failed. zsh: 22948 abort ./a.out This is with CVS alsa-utils (and 0.9.6 or 0.9.8), whatever is in 2.6.0 test9, and an SBLive. It goes away if the sample rate block is uncommented. I've tested this on a different machine; it's happening on both snd_intel8x0 and snd_emu10k1, with 2.6.0 (final) and current CVS alsa-lib. -- Glenn Maynard --- 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_id=1278alloc_id=3371op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] CS46xx oddness
(2.6.0 test11) I'm seeing something odd with a CS46xx chip: if I don't set a buffer size, or if I set it to 4k or 8k, then sound isn't played. The buffer fills up, and the device stays in SND_PCM_STATE_RUNNING. If I set it to 16k or 32k, it works. I'm testing remotely on a user's machine, so I can't do much to troubleshoot this (I'm not going to mess with his kernel). In case anyone's feeling brave, the relevant code is at http://cvs.sf.net/viewcvs.py/*checkout*/stepmania/stepmania/src/arch/Sound/ALSA9Helpers.cpp?rev=1.12 For reference, samplerate is 44100, channels is 2, and all dsnd* are just pointers to snd*. Sorry for not making a test case; it's 4am, so I can't do it tonight, and this is a drop-in on IRC so I may not get access to this machine again. If nobody feels like looking at that at all, I'll understand. :) If it helps, here's /proc/asound/card0/pcm0p/sub0/* with an 8k, full buffer: access: MMAP_INTERLEAVED format: S16_LE subformat: STD channels: 2 rate: 44100 (44100/1) period_size: 8 buffer_size: 8192 tick_time: 1000 card: 0 device: 0 subdevice: 0 stream: PLAYBACK id: CS46xx name: CS46xx subname: subdevice #0 class: 0 subclass: 0 subdevices_count: 31 subdevices_avail: 30 64 state: RUNNING trigger_time: 1072258017.688694000 tstamp : 1072258028.517208000 delay : 512 avail : 7680 avail_max : 7680 - hw_ptr : 0 appl_ptr: 512 tstamp_mode: NONE period_step: 1 sleep_min: 0 avail_min: 8 xfer_align: 8 start_threshold: 0 stop_threshold: 1073741824 silence_threshold: 0 silence_size: 0 boundary: 1073741824 -- Glenn Maynard --- 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_id=1278alloc_id=3371op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] pcm_plug.c:882: snd_pcm_plug_hw_params: Assertion `err = 0' failed.
The attached program results in:
./a.out
a.out: pcm_plug.c:882: snd_pcm_plug_hw_params: Assertion `err = 0' failed.
zsh: 22948 abort ./a.out
This is with CVS alsa-utils (and 0.9.6 or 0.9.8), whatever is in 2.6.0 test9,
and an SBLive. It goes away if the sample rate block is uncommented.
This only seems to happen with the plug device; it works fine with hw:0.
It also goes away if I don't specify a buffer size (which is why I havn't
seen this problem until now).
(What I'm really doing is setting up the subdevice on initialization,
and then when a sound really starts playing, I reconfigure it to the
sample rate of the sound. This works very well in Windows: it lets the
drivers resample, possibly in hardware, so I don't have to--the resampling
code I'm using is too slow. I havn't tested it as thoroughly in ALSA,
but it seems to work.)
--
Glenn Maynard
#define ALSA_PCM_NEW_HW_PARAMS_API
#define ALSA_PCM_NEW_SW_PARAMS_API
#include alsa/asoundlib.h
#define ALSA_CHECK(x) \
if ( err 0 ) { printf(ALSA9: %s: %s\n, x, snd_strerror(err)); return false; }
main()
{
/* Open the device. */
int err;
snd_pcm_t *pcm;
err = snd_pcm_open( pcm, default, SND_PCM_STREAM_PLAYBACK, SND_PCM_NONBLOCK );
assert( err = 0 );
/* allocate the hardware parameters structure */
snd_pcm_hw_params_t *hwparams;
snd_pcm_hw_params_alloca( hwparams );
err = snd_pcm_hw_params_any(pcm, hwparams);
ALSA_CHECK(snd_pcm_hw_params_any);
/* set to mmap mode (with channels interleaved) */
err = snd_pcm_hw_params_set_access(pcm, hwparams, SND_PCM_ACCESS_MMAP_INTERLEAVED);
ALSA_CHECK(snd_pcm_hw_params_set_access);
/* set PCM format (signed 16bit, little endian) */
err = snd_pcm_hw_params_set_format(pcm, hwparams, SND_PCM_FORMAT_S16_LE);
ALSA_CHECK(snd_pcm_hw_params_set_format);
/* set number of channels */
err = snd_pcm_hw_params_set_channels(pcm, hwparams, 2);
ALSA_CHECK(snd_pcm_hw_params_set_channels);
// unsigned int rate = samplerate;
// err = snd_pcm_hw_params_set_rate_near(pcm, hwparams, rate, 0);
// ALSA_CHECK(snd_pcm_hw_params_set_rate_near);
snd_pcm_uframes_t periodsize = 1024*32;
err = snd_pcm_hw_params_set_buffer_size_near( pcm, hwparams, periodsize );
ALSA_CHECK(snd_pcm_hw_params_set_buffer_size_near);
/* write the hardware parameters to the device */
err = snd_pcm_hw_params( pcm, hwparams );
ALSA_CHECK(snd_pcm_hw_params);
}
Re: [Alsa-devel] OpenAL- ALSA advanced features hardware support update.
(Oops. Sent privately unintentionally; resending to the list.) On Sun, Dec 21, 2003 at 11:24:00PM -0400, Manuel Jander wrote: The same as for the first iteration of this proposal, please take some minutes and give some comments/suggestions back. I need feedback. I'll give some higher level feedback: Why OpenAL? I looked at it about a year ago, while rewriting the sound system for a game with relatively strict sound demands. (StepMania; we wanted hardware mixing, when possible, and sound-to-gameplay sync to be as tight as possible, within a couple ms). I couldn't find any active mailing lists. I couldn't even find any indication that anyone was working on it at all. I read some of the Windows source code, and saw what is--without exaggeration--some of the most heinous, seizure-inducing code I've ever seen. (There were conditionals and loops nested something like 12 levels deep. I don't think the programmer understood the concept of the return keyword.) And although the API was decent to look at, it had no way of getting an accurate hardware play cursor, or any other mechanism to get a good idea of the currently-playing sample (for eg. graphical sync). We couldn't reliably sync sound with any smaller resolution than a whole buffer. I don't think OpenAL has a future. Do you really want to invest your time in it? -- Glenn Maynard --- 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_id=1278alloc_id=3371op=click ___ Alsa-devel mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/alsa-devel
[Alsa-devel] Detecting ALSA OSS emulation
Is there a reliable way to find out if /dev/dsp is being handled by ALSA? I want to be able to detect this for diagnostics. (If /dev/dsp is ALSA, the native alsa-lib code should have been used, and something has gone wrong.) Currently, I'm checking for the existance of /proc/asound/version, but at least one user had a configuration where that file existed but /dev/dsp was really OSS. (That's what it looked like, and what he claimed, at least; I havn't tried to reproduce that configuration, with both ALSA and OSS loaded and only OSS actually handling sound. It's possible something else was happening and the user was wrong.) -- Glenn Maynard --- 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] Detecting ALSA OSS emulation
On Mon, Dec 08, 2003 at 01:15:18PM +0100, p z wrote: Probably user has normal soundcard handled by ALSA and TV card (btaudio or saa7134) which provides only OSS drivers (warning - only recording - not playback). TV card is default /dev/dsp (can by changed by module option for btaudio, saa7134). For BT87x users there is alsa driver in ALSA 1.0.0rc2 for saa7134 not. Err, no, this user's configuration didn't have a working ALSA at all. dsnd_pcm_open returned ENOENT. His other applications were likely all using /dev/dsp, too. However, since /proc/asound/version existed, my code figured that ALSA was loaded and complained (/dev/dsp? why isn't ALSA being used?) -- Glenn Maynard --- 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
