search for: ao_play

Hi Gunter, I think this problem started happening when I upgraded from Debian Wheezy to Debian Jessie. If nothing looks amiss in my code, it probably is a sound driver problem. But since it works 100% of the time in ogg123, I feel I must have missed some corner case. My audio driver is almost always active. I usually have my music player going in the background when I do my testing. The problem

Hi Gunter, I've solved the sound glitch. Since it was hard to reproduce, it took me a while, but I eventually figured it out. What I needed to do was fill the buffer with more data before handing it off to ao_play. It requires lots of bookkeeping, pointer arithmetic, and a sufficiently large buffer. First, the bigger buffer. I just pulled this code from ogg123: #define PRIMAGIC (2*2*2*2*3*3*3*5*7) #define AUDIO_CHUNK_SIZE ((16384 + PRIMAGIC - 1)/ PRIMAGIC * PRIMAGIC) char convbuffer[AUDIO_CHUNK_SIZE]; cons...

...ling with this for some time, so I'm finally breaking down and trying this list. I'm trying to integrate libvorbisfile and libao to create a simple sound file player, a la ogg123. To do this, I borrowed heavily from ao_example.c and vorbisfile_example.c. I feed the buffer from ov_read into ao_play in a simple loop. It usually works, but occasionally all it does is make a strange sound and quickly finishes. I cannot dependably reproduce it. The same problem does not happen when I use ogg123, so I'm sure I'm doing something wrong. I've combed through the ogg123 source code and coul...

...me so I don't trip over this again later in my project? I used sf_open_fd() to get a SNDFILE* pointer and an AF_INFO struct. In that struct I find out what bit resolution the samples are. I put that number into ao_sample_format format.bits, fill a buffer using sf_read_int() and then call ao_play(). Doing this with a file containing 8-bit samples, the result was the file playing at at half-pitch and twice as long as normal. But, if I manually plug in format.bits = 32, the files play fine. Here's the program: /* compile with "gcc -o foo foo.c -lao -ldl -lm -lsndfile" */...

...annels = nchan ; // channel count fmt.byte_format = AO_FMT_NATIVE ; fmt.matrix = "L,R" ; if ( ( device = ao_open_live(id, &fmt, NULL) ) == NULL ) { fprintf(stderr,"Error in ao_open_live()\n") ; exit(EXIT_FAILURE) ; } if ( ( r = ao_play(device, sound, nBytes) ) == 0 ) { fprintf(stderr,"Error in ao_play()\n") ; exit(EXIT_FAILURE) ; } if ( ( r = ao_close(device) ) != 1 ) { fprintf(stderr,"Error in ao_close()\n") ; exit(EXIT_FAILURE) ; } ao_shutdown() ;...

...ug for me to investigate. I was hoping that something would be immediately obvious in my code to those who know these libraries very well. I have the feeling it has something to do with buffering. If I decode the Ogg Vorbis file and dump it into a raw file, and then read it in again and feed it to ao_play, the problem goes away. I have a simple Ogg Vorbis file I am using for testing, which I sent to you in a private email. I have no server space on which to store it. Thanks, Marshall On Sat, Jun 13, 2015 at 10:14 PM, Gunter K?nigsmann <gunter at peterpall.de> wrote: > How can this probl...

...'m finally breaking > down and trying this list. > > I'm trying to integrate libvorbisfile and libao to create a simple > sound file player, a la ogg123. To do this, I borrowed heavily from > ao_example.c and vorbisfile_example.c. I feed the buffer from ov_read > into ao_play in a simple loop. It usually works, but occasionally all > it does is make a strange sound and quickly finishes. I cannot > dependably reproduce it. The same problem does not happen when I use > ogg123, so I'm sure I'm doing something wrong. I've combed through > the ogg...

Why has ao been changed so that there are now two open() functions ? IMHO the original ao_open() was fine - if you wanted to set the filename for output, you could add an option via ao_append_option and if you wanted to avoid overwriting an existing file, you could stat() it yourself. Having ao_open_live() and ao_open_file() just makes more work for the user of the library for no gain, AFAICT.

Why has ao been changed so that there are now two open() functions ? IMHO the original ao_open() was fine - if you wanted to set the filename for output, you could add an option via ao_append_option and if you wanted to avoid overwriting an existing file, you could stat() it yourself. Having ao_open_live() and ao_open_file() just makes more work for the user of the library for no gain, AFAICT.