New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
freewheeling (was OSC doc) #10
Conversation
PS. maybe this can all go into --advanced-options That help is already loong enough a few more lines won't hurt. OTOH, personally I prefer if usage information is structured rather than a big blob: I don't want to read about OSC unless I want to know about OSC. :) YMMV. |
can you fix the typo on merge? I guess that's faster than opening another pull request... |
I don't get any over or underruns (because the buffer increases a LOT) - but you're right about the autoincrease callback. Once that is in place, there are lots of internal x-runs. This needs a bit more work.. |
in freewheeling- mode: actually the jack_callback should wait until the buffer is flushed! |
Sorry for late reply, I didn't see your comments here. Just wait until flushed is probably the simplest. Is your tree working properly now? Should I merge it into my branch? |
Sorry, I did mess up this pull request. Lemme see if I can clean it up a bit, since you've already merged the OSC doc. yes, the it is working properly -- but I have only tested and not any edge cases that may or may not exist. |
Right, it took a push --force, because I've rebased the two commits, but it's clean now. |
@@ -2112,6 +2139,10 @@ void init_arguments(int argc, char *argv[]){ | |||
OPTARG_LAST() base_filename=OPTARG_GETSTRING(); | |||
}OPTARGS_END; | |||
|
|||
if(use_jack_freewheel==true && use_jack_transport==true){ | |||
fprintf(stderr,"--jack-transport and --jack-freewheel are exclusive options.\n"); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
maybe this should read "mutually exclusive" ?!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that sounds more correct.
BTW it also misses a ChangeLog entry.. But please review the code first and I'll do all corrections after that. |
Hmm, waiting a couple of milliseconds could cause freewheeling to take very long time to finish. I think that instead of waiting until it's flushed, just wait until enough space is available before writing. |
I think this is much better: static bool process_new_current_buffer(int frames_left){ |
Ow, too late :) Well why don't you go ahead, merge it and fix it. That's much faster, you know your way around much better than I do and it's a few lines only.. |
No problem. But now I wonder if it's a good idea... If we're using the buffer to its fullest, freewheeling could finish a long time before the sound is actually written to the disk. Do you know if that could be a problem? |
jack_capture will of course write the complete sound to disk, it won't just cut off. But it could take some time before it finishes. Perhaps a script or something could expect the file to be available directly after freewheeling is finished. |
freewheeling (was OSC doc)
good points. Compared it to Fons' tool: it keeps sleeping for 1/2 seconds in main until freewheeling mode ends and then closes the file. So when jack issues a "jack-freewheeling ended" callback, the file may not yet be complete on disk. I can't think of a good use-case that would require the file to be flushed to disk when jack issues the callback but that does not mean there is none. -- Worst case would have to wait until jack_capture exits. re buffer-usage: right, it would be a bit faster, but I think this is a non-issue. |
actually the usleep() is ugly. -- it should block on a signal from the disk-writer thread rather than wait and poll it. on that note: can it happen that vringbuffer_get_reading_size(vringbuffer) won't return to 0? the receiver_func() has a |
I think we should keep usleep() calls, (BTW, there is an msleep function available in jack_capture.c), since sleeping is simpler to understand than signalling. Also, I just tried to wait until the buffer is availble, instead of waiting for the buffer to flush, and it seems 10 times faster now! To ensure the buffer is fully written, we can just flush it in the freewheel callback, when the argument is 0. |
I'm pretty sure that vringbuffer_get_writing_size(vringbuffer) must return 0 after a while. If not, we would have noticed glitches in sound. vringbuffer would be buggy if it sometimes wouldn't return 0 after a while. |
I meant vringbuffer_reading_size |
Fixed here: |
I think you're right. vringbuffer_reading_size can actually not return 0 after a while. We need to call sem_post() to ensure. Must fix. |
That's a really good catch by the way! |
Think this is enough: |
Re-using this "already open pull request"
http://kokkinizita.linuxaudio.org/linuxaudio/downloads/jack_export-0.0.1.tar.bz2 )
OSC documentation: done
please proof-read and see it it makes sense :)