similar to: Decode ogg file while downloading: what are the good practices?

Thanks for your answer. But as I said, I don't have any problem seeking in a local file. Also, I have full control on the ogg file I play, since I encode it by myself. I first would like to know if the code I provided ( https://gist.github.com/mregnauld/3f7cdc43b02ec3bbd91641b9333ba072) is good practice when it comes to extracting and seeking in a file that is being downloaded. Thanks.

Hello, After more tests, I discovered a new problem in my code ( https://gist.github.com/mregnauld/3f7cdc43b02ec3bbd91641b9333ba072) while seeking in an audio file that is being downloaded. When I seek in random positions (when I call OggPlayer::seek()), while I extract audio samples (when I call OggPlayer::extract() every 5ms, in my test - basically, I just play the audio file), sometimes, I

Can you get a backtrace that tells in which line of the code of the library it crashes? Not that you did Fuzzing using incomplete files and found a bug. Am 5. November 2018 20:46:21 MEZ schrieb Matthieu Regnauld <mregnauld at gmail.com>: >Hello, > >After more tests, I discovered a new problem in my code ( >https://gist.github.com/mregnauld/3f7cdc43b02ec3bbd91641b9333ba072)

I'm making all my calls from the same thread, yes. Also, I'll try to reproduce the bug in a very basic C/C++ project, without using Android, so I can get a stacktrace (the only way to make vorbisfile work in Android was to compile it as a static library - as .a file - so I think that's why I can't get any stacktrace so far). If there is any working similar project, I'm

On 2018-11-03 05:32 AM, Matthieu Regnauld wrote: > I first would like to know if the code I provided > (https://gist.github.com/mregnauld/3f7cdc43b02ec3bbd91641b9333ba072) is > good practice when it comes to extracting and seeking in a file that is > being downloaded. You didn't share many details of how your code fails, but one idea: libvorbisfile builds a seek table from

OK, thanks for the information. > Is the overhead of closing and re-opening the handle significant on android? Not that much: I can close, reopen and seek in a file right before extracting samples to play a second audio file, while a first file is already extracting and playing, without any glitch, even on low-end device. -------------- next part -------------- An HTML attachment was

Well, your " OggPlayer::release; OggPlayer::open; before OggPlayer::seek" seems to work! Thank you so much! Also, I'll take a look at the Opus codec, thanks for the advice! For your information, here was the problem in details: let's say I download an audio file whose length is 300 seconds. When, for example, 15 seconds of the file were downloaded, I called OggPlayer::open().

I haven't managed yet to get any stacktrace, but I'll work on it (that's the problem using C/C++ code in an Android app...). Also, it's important to notice that I manage to make ov_read() crash, *even when the audio file is fully downloaded!* What I do to reproduce the bug is to call ov_pcm_seek() (without any reload of the file) many times in a row, very quickly (like 6-7 times

Hello, Since last week I started having random ogg files from my library turning corrupt, and practically being unplayable by anything. All this while I was browsing and sorting my library through Amarok. Luckily today I've found the possible culprit, Amarok itself, and others who may have the issue as well: https://bugs.kde.org/show_bug.cgi?id=369672 But regardless of how the issue started,

On 2018-11-03 02:18 PM, Matthieu Regnauld wrote: . > When, for example, 15 seconds of the file were downloaded, I called > OggPlayer::open(). > After that moment, even if the file was fully downloaded, I was able to > seek in the file, but only between 0 and 15 seconds (whether I > useov_pcm_seek() or even ov_raw_seek()). That all seems consistent. Glad the work-around was

Hi! For the files that are in the share Regards; On 18-07-2018 18:09, Micha Ballmann wrote: > You mean your Samba shares? For fure. > > Regards > > Am 18. Juli 2018 22:54:28 MESZ schrieb Carlos via samba > <samba at lists.samba.org>: > > Hi! > > I would like to know if I can use GlusterFS to replicate the files in my > samba domain member?

How do I seek back to the beginning of a stream using ov_pcm_seek()? ov_pcm_seek(0) doesn't seem to do anything, though ov_pcm_tell() returns 0 right after opening the stream. I'm now using ov_pcm_seek(1) which seems to work, but I'm not sure if that's really right. Are PCM offsets meant to be 0 or 1 based? Is this a bug? Frank -- Frank Heckenbach, frank@g-n-u.de

Hi all, I'm having a little trouble with a Vorbis decoder hanging (actually hard looping the CPU) when I call ov_pcm_seek(&vorbis_file, 0) on a multiplexed theora/vorbis file. It appears to be the vorbisfile library that has the problem. The call to ov_pcm_seek never returns. Seeking in non-multiplexed, including chained, files is OK. Seeking to other values, including sample 1, works

Hi! I would like to know if I can use GlusterFS to replicate the files in my samba domain member? Regards;

I have been having problems compling vorbis on my computer( running redhat 7.1 ), it gives me a bunch of errors about vorbisfile.o( at least that what the errors are complaining about...I don't know enough to figure out what is wrong ). Below is the output I get from compile: Making all in examples make[1]: Entering directory `/home/mchavez/devel/vorbis/examples' /bin/sh ../libtool

I have been having problems compling vorbis on my computer( running redhat 7.1 ), it gives me a bunch of errors about vorbisfile.o( at least that what the errors are complaining about...I don't know enough to figure out what is wrong ). Below is the output I get from compile: Making all in examples make[1]: Entering directory `/home/mchavez/devel/vorbis/examples' /bin/sh ../libtool

I found a problem with ov_raw_seek function in oggvorbis win32sdk 1.0. When i called this function it returned OV_EINVAL immediatelly. I solved the issue by replacing the ov_raw_seek by ov_pcm_seek, which worked perfectly, but i would like to use the raw variant due to performace reason . Is anybody aware of this strange behaviour ? Martin Cesky <p><p>--- >8 ---- List

Hi, Where is the mount option 'limit-rate' in the current version? I checked in cfgfile.c and in the documentation, no mention. Yet this option did exist at one time: http://lists.xiph.org/pipermail/icecast/2010-October/011703.html http://lists.xiph.org/pipermail/icecast/2009-January/011391.html I try to limit the bitrate of a mount-point, is there another solution? Do you know why this

Hi, I have been having some problems with ov_pcm_seek in vorbis_file:- Any seeks to a sample within the first second of the stream (i.e. < 44100 samples) fail. Seeks to samples beyond this 44100 limit are fine. It appears to be associated with vorbis_file trying to read the preceding page (odd for the beginning of the file), attempting an ov_raw_seek, then bombing out with an OV_EINVAL.

I realise the it's hard to do a seek in a variable bitrate file but I didn't think it was this bad. It seems to vary a lot with the file but the total time to do an ov_open() and ov_pcm_seek() can add upp to a second or more. By this time my DirectX buffers have wrapped around and are looping. Can anybody think of a solution for this? I really need a faster response time for my in-game