similar to: Problem with ov_read_float()

Hello, Am I missing something? float** pcm_channels; int bitstream; int where = ov_pcm_tell(&vf); -> The Result is "0"; ov_read_float(&vf, &pcm_channels, 1, &bitstream); -> pcm_channels[0][0] is "0.000338580" ov_pcm_seek(&vf, 0); char* buffer = new char[2]; ov_read(&vf, buffer, sizeof(buffer), 0, 2, 1, &bitstream); short temp =

Hi, in ov_read_float.html there is a small mistake: long ov_read(OggVorbis_File *vf, float ***pcm_channels, int *bitstream); hould read: long ov_read_float(OggVorbis_File *vf, float ***pcm_channels, int samples, int *bitstream); It seems this function has been changed (compared to the RC3). Anything else worked fine for me with the 1.0 release. Olaf <p>--- >8 ---- List archives:

Hello, hope you're fine. And hopefully someone can help me. I wrote a short demonstration to show you my problem (see below). I'm asking always for 64 samples. When "ov_read_float()" is finished, I want to seek back to sample 1, and ask immediately for the next 64 samples. But when I run this small app, I get an totally high CPU load. Is there a way to it speed up? Or do I

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

Subj!. Kind Regards, Michail. _________________________________ Michail A.Baikov, Linderdaum Team http://www.gamedot.ru http://linderdaum.gamedot.ru <p><p><p>--- >8 ---- List archives: http://www.xiph.org/archives/ Ogg project homepage: http://www.xiph.org/ogg/ To unsubscribe from this list, send a message to 'vorbis-dev-request@xiph.org' containing only the word

Hello, has anyone experience with "CoreAudio" and "Vorbis" ? I try to decode a file with ov_read(...). It works for some (mili)seconds and then the Output get into trouble... . You need some infos? char buffer[4096]; OSStatus Render(...) { bytes_read = ov_read(&vf, buffer, sizeof(buffer), 0, 2, 1, &current_section); memcpy(ioData->mBuffers[0].mData,

I've been experimenting with the ideas of Replay Gain[1] and find that ogg123 doesn't have a way of specifying the scaling applied to replayed samples (like -f in mpg123). Looking at libvorbisfile, I see no function exactly matching this possibly desirable behaviour. ov_read() scales by either 128 (byte output) or 32768 (word output), but there's nothing in between. ov_read_float()

Hello. I noticed that when reading data with ov_read_float(), you can get values outside [-1..1] when the stream is encoded at lower quality, but with higher quality, the values trim down to inside [-1..1]. Looking at the plot from -q10, the data from ov_read_float seems clipped. I've made some plots of encoding the start of Rammsteins Feuer from the xXx soundtrack (it's a pretty loud

On Wed, Jul 02, 2014 at 03:58:15PM +0530, Amit Shah wrote: > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > added a call to rng_get_data() from the hwrng_register() function. > However, some rng devices need initialization before data can be read > from them. > > Also, the virtio-rng device does not behave properly when this call is > made

On Wed, Jul 02, 2014 at 03:58:15PM +0530, Amit Shah wrote: > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > added a call to rng_get_data() from the hwrng_register() function. > However, some rng devices need initialization before data can be read > from them. > > Also, the virtio-rng device does not behave properly when this call is > made

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

Commit d9e7972619334 "hwrng: add randomness to system from rng sources" added a call to rng_get_data() from the hwrng_register() function. However, some rng devices need initialization before data can be read from them. Also, the virtio-rng device does not behave properly when this call is made in its probe() routine - the virtio core sets the DRIVER_OK status bit only on a successful

On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote: > Hi Jason, > > On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > added a call to rng_get_data() from the hwrng_register() function. > > However, some rng devices need initialization before data can be read > >

On Wed, Jul 02, 2014 at 06:56:35PM +0530, Amit Shah wrote: > Hi Jason, > > On (Wed) 02 Jul 2014 [13:00:19], Jason Cooper wrote: > > Commit d9e7972619334 "hwrng: add randomness to system from rng sources" > > added a call to rng_get_data() from the hwrng_register() function. > > However, some rng devices need initialization before data can be read > >

Hi, I need to adjust the output volume from ogg123 the same way that mpg123 has the "-f n change scalefactor [32768]" option. I need to do this within ogg123, instead of alternatives that involve pipes, such as piping the output to sox. I do not believe that this is currently possible in ogg123, and I'm looking for some suggestions as to how it can be accomplished by modifying

Hi, I need to adjust the output volume from ogg123 the same way that mpg123 has the "-f n change scalefactor [32768]" option. I need to do this within ogg123, instead of alternatives that involve pipes, such as piping the output to sox. I do not believe that this is currently possible in ogg123, and I'm looking for some suggestions as to how it can be accomplished by modifying

A bit late to a party, but: On Mon, Dec 8, 2014 at 12:50 AM, Amos Kong <akong at redhat.com> wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > There's currently a big lock around everything, and it means that we > can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current) > while the rng is reading. This is a real problem when the rng is

A bit late to a party, but: On Mon, Dec 8, 2014 at 12:50 AM, Amos Kong <akong at redhat.com> wrote: > From: Rusty Russell <rusty at rustcorp.com.au> > > There's currently a big lock around everything, and it means that we > can't query sysfs (eg /sys/devices/virtual/misc/hw_random/rng_current) > while the rng is reading. This is a real problem when the rng is

Is there any particular reason why ov_read() packs floats to integer PCM inline, rather than being implemented in terms of ov_read_float() and a separate packing fucntion? There are obviously many advantages doing audio manipulation on the floats before packing, but right now you have to reinvent the packing stage yourself - in a replaygain backend that I'm working on, I ended up copying

I had completely forgotten about Replay Gain until Mr. Seibert reminded me. Wasn't there talk of adding this to vorbis-tools? Anyway, I went here: http://sjeng.sourceforge.net/ftp/vorbis/ And downloaded the source for the replay gain tool. Unfortunately, I cannot compile it. The errors regard parameters to ov_read_float. Is there updated source somewhere else? -- -:-:-