similar to: libao problem (Re: [alsa-devel] No dmix/dsnoop on Intel ICH4/5 by default?)

The enclosed patch to ao_alsa.c (src/plugins/alsa/ao_alsa.c) fixes (after a fashion) a problem I had with interrupted snd_pcm_write() calls. Apparently this behaves like write() rather than fwrite() and needs to be handled accordingly. The fix is dirty, but it gets the thing working. The patch is against the 0.8.0 version of libao, but I believe the latest ao_alsa.c from CVS is similar (if not

Hey' Can't seem to compile libao. I'm using Slackware-7.1-current-ish, linux-2.4.2, gcc-2.95.2, and alsa-9.0-beta2. This is the first time I've tried to compile libao so I don't know if the problem is related to alsa-9.0 changes. Alsa headers seem to be there: /usr/include/linux> ls -l as*.h -rw-r--r-- 1 root root 35994 Mar 3 10:57 asequencer.h -rw-r--r-- 1

Compiling libao on a system w/linux2.4.2 & glibc-2.0 (I think), I get an error. gcc -DPACKAGE=\"libao\" -DVERSION=\"0.6.0\" -DSIZEOF_SHORT=2 -DSIZEOF_INT=4 -DSIZEOF_LONG=4 -DHAVE_SYS_SOUNDCARD_H=1 -I. -I. -I../../.. -I../../../include -O20 -ffast-math -D_REENTRANT -fsigned-char -DAO_PLUGIN_PATH=\"/usr/local/lib/ao\" -c ao_alsa.c -fPIC -DPIC -o ao_alsa.lo In file

remember kenneth that libao has moved to the "ao" module, so copy the changes... jack. ----- Forwarded message from "Kenneth C. Arnold" <kcarnold@xiph.org> ----- Delivered-To: cvs-outgoing@xiph.org Delivered-To: cvs@xiph.org To: cvs@xiph.org Subject: [xiph-cvs] cvs commit: vorbis/vorbis-tools/libao ao_alsa.c ao_oss.c audio_out.c audio_out.h Date: Tue, 5 Sep 2000

Here is a patch to fix the compiler warnings I mentioned earlier. I've removed the byte-order changes that don't make sense. (Thanks Michael for pointing out the error!) As for the byte-order changes, since some output modules don't have the option to set the sample byte-order, I would like to standardize libao and ogg123 on native byte-order. Will this break the ao_wav.c patches

Hi! There are some little inconvenience in libao-0.8.5. - The biggest is may that: the documentation and the header file declare the ao_file_extension function, which give a hint for the file extension where the device is realy a sound file. This function is missing. -An other: the alsa 0.5 and the alsa 0.9+ drivers short name. It will be better if the alsa 0.5's name will be alsa05 and the

The attached patch for src/plugins/alsa/ao_alsa.c supersedes the one I posted last night (well, this morning actually...) The changes are: Handling of incomplete snd_pcm_write()s that actually works (hey, I was sleepy when I wrote the other one). Padding of the playback buffer with zeroes to meet the N*fragment size requirement for snd_pcm_write(). (It might be better to use stream mode

I have searched all around and combined items in an /etc/asound.conf file to have by default a capture and multiple playback for alsa. I am looking for a way to: something like "aplay --nonblock test.wav" having at least 2 active one time and at that same time do "arecord --nonblock -d 1 input.wav" I have something like: pcm.!dmixer { type dmix

Hello, I found a bug by metadata updating in ices-2.0.0. I use icecast2 server for streaming stations of Czech Radio. Czech Radio prefers streaming in both formats mp3 and ogg. So - I'm using DarkIce as a live audio streamer, which does encoding to mp3 and ogg streams together. I would like to insert textual information about actual streaming program, but DarkIce does not support it. So -

Hello I've discovered, that sending a SIGUSR1 signal to ices causes it's shutdown when recording from an alsa dsnoopped device. > [2004-11-01 18:51:51] INFO signals/signal_usr1_handler Metadata update requested > [2004-11-01 18:51:51] DBUG metadata/metadata_thread_signal meta thread wakeup > [2004-11-01 18:51:51] DBUG stream-shared/stream_wait_for_data Shutdown signalled:

Hello Everybody I got some little issues with the sound. Logged in as my normal user - I've the testsound (winecfg) on the internal device. I can't change it. If I log in as root I've the testsound on my external USB speakers (the way I would prefer it works). I can't Imagine me - why there is a different between root and my normal user. Please find below some details. Code:

My problem is this. I am connected via fwd's iax protocol. I try to call the echo test, sometimes I get an answer, sometimes not. When I do, sound is about one second lagged - I still hear the ring about a second after I get the answering on console message, and the echo test takes about a second or second and a half to get back the answer. When I use asterisk with dmix and dsnoop, calling

Hello, I can't get the sound over alsa to work with Asterisk. My current version is 1.4.21.2~dfsg-3 running on debian stable. All settings are the default ones with exception of: /etc/asterisk/modules.conf: load => chan_alsa.so noload => chan_oss.so /etc/asterisk/alsa.conf: input_device=default output_device=default asterisk is started up and doesn't complain about alsa in

Hi, I sent the below a few days ago. It still hasn't turned up in the archive so i'm trying again. Since the first mail was sent, i've found out that removing the call to *_set_periods and *_set_period_size is a better solution to the problem. It seems that the alsa defaults are better than what ever fine tuning the code is trying to do. patch: ---

Here is a patch that makes ao_alsa.c support alsa 0.9. Device parameter "card" is gone from the 0.9 version and "dev" has changed from numeric to string and defaults to "default" (another possibility is "plughw:0,1"). The configure.in changes cover allowing alsa 0.9 and /not/ having arts-dev (or whatever it is) installed. Bill (taniwha) -- Leave others

I had a go at building libao-0.6.0 and it barfed on the alsa output part, complaining that snd_pcm_channel_status_t is undeclared - probably due to me running alsa 0.9.0 beta4. So the question is, should I try and beat the configure stuff into letting me disable alsa support and just use OSS, or would I be better off trying my luck with the nightly builds? And if so, can I get away with just

I had a go at building libao-0.6.0 and it barfed on the alsa output part, complaining that snd_pcm_channel_status_t is undeclared - probably due to me running alsa 0.9.0 beta4. So the question is, should I try and beat the configure stuff into letting me disable alsa support and just use OSS, or would I be better off trying my luck with the nightly builds? And if so, can I get away with just

(Hi, this isn't exactly vorbis related, but I figure most of you use libao with ogg123.) Libao 0.8.4 has been released today. It's mostly a bug-fix release, but has some new drivers too! We've also moved libao to it's own website: http://www.xiph.org/ao/ Source, RPMS for RedHat 9, and Debian packages are there. Enjoy! Changelog: * Incorporated OS X patches from the Fink

I am trying to get audio to play on Pulse - so just the monitor basically. I have tried Console/dsp, Console/dmix, Console/pulse, and a couple others. The error is always the same "console_request: Console device 'dmix' not found. What is the correct "Console/XXXX" to play on pulse for UBuntu 20.04 LTS ? I can "aplay /usr/share/sounds/alsa/Front_Center.wav" no

Hi, I found the main reason for sound distortions on my system is guest timer configuration. The working one is: <clock offset="localtime"> <timer name="hypervclock" present="yes"/> <timer name="hpet" present="no"/> <timer name="rtc" present="yes" track="guest"