similar to: libao patch: Minor clean up / Byte-order proposal

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

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

Hi, I noticed there was some discussion on this list about the desire for ogg123 to support output to stdout via Sun's .au file format, so I decided to give implementing an AU driver for libao a shot. Here is my first attempt. To test the driver: * Apply the patch below (against ao in CVS) * Copy the attached ao_au.c into ao/src * Run ao/autogen.sh, compile, and

I hope this is the right place to submit libao patches -- the freshmeat page points to ogg vorbis as the homepage for libao. Currently, at least on my system (SB Live Value!, ALSA .9 branch), stuff going to alsa sounds *awful* because of too-small buffers. mpg321 and similar programs are unusable, and none of them seem to want to let you set the buffer size. This patch lets an environment

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

On 09 February 2018 15:56 Jean-Marc Valin wrote: > Pointers are unsigned so this shouldn't be an issue. I suspect you're > being hit by something else. That or your compiler is really broken. I don't know how important it is in this case (probably pretty minor) but in general Ruikai's right. It doesn't matter that pointers are unsigned; that fact that a pointer could

Yes, I agree that buf_end - buf_start < len_to_check is better. It's the 0xFFFFFFFF overflow that's a cause of concern, not the 0x80000000. That being said, I believe that the length argument in this case can be trusted since it comes from the application and not from the user. Cheers, Jean-Marc On 02/12/2018 05:28 AM, Nicholas Wilson wrote: > On 09 February 2018 15:56 Jean-Marc

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

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: ---

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

I submitted four new packages for the NetBSD pkgsrc collection: libao, libogg, libvorbis and vorbis-tools for 1.0beta4. The following is some of the patches needed for libao and vorbis-tools. Official Developers: When you receive patches or development suggestions can you please acknowledge them? (For example: "Noted.", "Thanks, but already done.", "Not necessary,

Below is a patch for vorbis-tools-1.0beta4 ogg123. It adds support for using the rc file (like /etc/ogg123.rc) for configuring the device-options. In addition, comments can be used (when they start a line). My ~/.ogg123rc: default_device=oss default_options=dsp:/dev/audio Please share your comments. Jeremy C. Reed http://www.reedmedia.net/ diff -u

On 16-01-13 21:52, Clemens Ladisch wrote: > Rene Herman wrote: >> I'm out of touch of with alsa -- but should dmix/dsnoop still be >> enabled by default on hardware that doesn't do hardware mixing? > > Yes. > >> I believe that it should be from /usr/share/alsa/cards/ICH4.conf, >> but I don't get mixing on this setup when using 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 decided to take a break from trying to get the encoding working in order to update my libraries to the latest versions I tried to build ao-python from both SRPM and tarball, and here's what I got: --- + python setup.py install --root=/var/tmp/pyao-buildroot --record=INSTALLED_FILES running install running build running build_ext building 'aomodule' extension creating build creating

I'm also working on writing the raw driver I mentioned in the last email, but noticed that Jack has rearranged some of the guts of ao since I last looked at it. In ao/include/ao/ao.h you define AO_NULL and AO_WAV to be 0 and 1, respectively. If I want to add a raw driver that is compiled into the main library, can I just add #define AO_RAW 2 and then modify ao_initialize to put ao_raw

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

Hi, I've written an ao plugin for aRts, the soundserver that comes with KDE. Any chance of including this in the ao distribution ? Pretty please ? :) Sources and patches attached. This is a very simple plugin because it uses the easy-to-use 'artsc' C wrapper that aRts installs. configure.in.diff is for ao/configure.in Makefile.am.diff is for ao/src/plugins/Makefile.am Makefile.am

Can someone apply this patch? It corrects a silly typo on my part. --- Stan Seibert ---------- Forwarded message ---------- Date: Wed, 07 Mar 2001 01:20:48 +0100 From: Markus Keller <markus@mercury.net.dhis.org> To: indigo@aztec.asu.edu Subject: ao patch Hi, I just noticed a small typo in ao_esd.c. Here is a patch for it: --- ao_esd.c~ Sun Feb 25 03:06:05 2001 +++ ao_esd.c Wed

Hi Dave, Please apply this compiler warning fix from Randy. Signed-off-by: Bart De Schuymer <bdschuym@telenet.be> Signed-off-by: Randy Dunlap <rddunlap@osdl.org> diff -Naurp ./net/bridge/netfilter/ebt_ulog.c~brnetf_types ./net/bridge/netfilter/ebt_ulog.c --- ./net/bridge/netfilter/ebt_ulog.c~brnetf_types 2005-01-10 10:38:40.531343592 -0800 +++ ./net/bridge/netfilter/ebt_ulog.c