| *** Yruama_Lairba has quit IRC | 00:26 | |
| *** artfwo has quit IRC | 01:56 | |
| *** son0p has joined #lv2 | 02:07 | |
| *** son0p has quit IRC | 02:21 | |
| *** grejppi_ has joined #lv2 | 02:33 | |
| *** grejppi has quit IRC | 02:35 | |
| *** drobilla has quit IRC | 03:50 | |
| *** diqidoq has joined #lv2 | 04:00 | |
| *** diqidoq has quit IRC | 04:55 | |
| *** diqidoq has joined #lv2 | 05:36 | |
| *** diqidoq has quit IRC | 06:39 | |
| *** oofus_lt has joined #lv2 | 06:39 | |
| *** ssam2 has joined #lv2 | 07:57 | |
| *** sigma6 has joined #lv2 | 08:06 | |
| *** drobilla has joined #lv2 | 10:02 | |
| *** diqidoq has joined #lv2 | 10:26 | |
| *** diqidoq has quit IRC | 10:53 | |
| *** diqidoq has joined #lv2 | 10:54 | |
| *** diqidoq has quit IRC | 11:17 | |
| *** JackWinter has quit IRC | 11:30 | |
| *** JackWinter has joined #lv2 | 11:33 | |
| *** drobilla has quit IRC | 11:52 | |
| *** yann-kaelig has joined #lv2 | 12:37 | |
| *** artfwo has joined #lv2 | 12:41 | |
| *** son0p has joined #lv2 | 13:11 | |
| *** HarryHaaren has joined #lv2 | 13:28 | |
| *** drobilla has joined #lv2 | 13:56 | |
| *** artfwo has quit IRC | 14:25 | |
| *** artfwo has joined #lv2 | 14:38 | |
| *** HarryHaaren has quit IRC | 15:01 | |
| *** dsheeler has quit IRC | 15:39 | |
| *** sigma6 has quit IRC | 15:51 | |
| *** artfwo has quit IRC | 15:51 | |
| *** artfwo has joined #lv2 | 16:07 | |
| *** HarryHaaren has joined #lv2 | 16:12 | |
| *** ssam2 has quit IRC | 16:37 | |
| *** gabrbedd has quit IRC | 16:40 | |
| *** gabrbedd has joined #lv2 | 16:42 | |
| *** rncbc has joined #lv2 | 17:45 | |
| *** nixlappy has quit IRC | 18:04 | |
| *** nixlappy has joined #lv2 | 18:05 | |
| *** HDaemon has joined #lv2 | 18:11 | |
| HDaemon | Hi everyone! | 18:11 |
|---|---|---|
| HDaemon | Have lv2rack issue in Ubuntustudio 17.04 | 18:13 |
| *** deva has joined #lv2 | 18:13 | |
| HDaemon | Hereis traceback: https://pastebin.com/uk2k2zQj | 18:14 |
| *** HDaemon has quit IRC | 18:19 | |
| rgareus | is lv2rack still a thing? I thought it died about 2009 with Nedko leaving | 18:23 |
| *** oofus_lt has quit IRC | 18:27 | |
| *** son0p has quit IRC | 18:40 | |
| arguy | Hi folks! I'm trying to build an lv2 plugin that uses the new xiph's RNNoise library and I'm building the library statically. The thing is that I got it to compile without errors but is not processing the signal as expected. Could that be a problem of how I'm linking against the static build of the library or more like a problem of the library itself. Code is here https://github.com/lucianodato/speech-denoiser if you are | 19:27 |
| arguy | interested | 19:27 |
| arguy | I'm a gnu-make noob so don't expect me to know what I'm doing. Sorry! | 19:29 |
| rgareus | arguy: static_rnnoise.sh looks fine to me. | 19:48 |
| rgareus | as does https://github.com/lucianodato/speech-denoiser/blob/master/Makefile#L59-L65 | 19:49 |
| arguy | Thanks rgareus ! I will talk to Xiph folks then | 19:52 |
| rgareus | arguy: knowing some xiph projects (e.g. opus) my first guess is that it doesn't like the buffersize. | 19:53 |
| rgareus | most of their tools are msec aligned. e.g. 480 sample chunks at 48k. | 19:54 |
| arguy | Could be. Although with a 48 khz session it does not work either | 19:55 |
| rgareus | arguy: check the return value of rnnoise_process_frame() | 19:55 |
| arguy | It's 0 | 19:56 |
| rgareus | not sure what it means, but it seems that 0 samples were processed. it seems to be phase-offset (float) though. | 19:57 |
| arguy | It's a percentage of voice detection if I'm not wrong | 19:58 |
| rgareus | that would make sense, indeed | 19:58 |
| arguy | the problem is when it reaches to compute frame features | 19:59 |
| rgareus | arguy: where do you tell rnoise how large the buffer is? | 19:59 |
| rgareus | oh it's one sample at a time? | 19:59 |
| arguy | the api of that library is not finished yet | 19:59 |
| arguy | yeah | 19:59 |
| arguy | FRAME_SIZE | 20:00 |
| arguy | needs to be hardcoded | 20:00 |
| rgareus | arguy: in any case your approach to statically link and use the library is correct. | 20:02 |
| rgareus | It could well be a bug in the lib (not ready for static usage) or perhaps the issue is elsewhere, how you use the API | 20:03 |
| arguy | Fantastic I was worried that I might be getting that wrong | 20:03 |
| rgareus | arguy: I think your fifo is not right though | 20:04 |
| rgareus | say your plugin gets called with 64 samples per cycle. | 20:04 |
| rgareus | you need to keep apending them an offset each cycle | 20:05 |
| rgareus | self->rnnoise_input_frame[k] = self->in_fifo[k]; seems wrong | 20:05 |
| rgareus | and self->read_ptr won't be the same for input and output | 20:05 |
| rgareus | arguy: in case there have not yet been enough samples to process. the output needs to be zeroed. | 20:07 |
| rgareus | alignement will be different. e.g. you get 7 * 64 samples = 448. no output, just store them. next 64 samples you have 512 total samples that's > 480 you process | 20:08 |
| arguy | Ohhh | 20:09 |
| rgareus | you have 32 samples left-over (512 - 480) = 32 that you need to keep. but you do write 64 sample of output from those 480 processed ones | 20:09 |
| arguy | yep my bad | 20:09 |
| rgareus | perhaps start jackd ... -p 480 and it'll work :) | 20:14 |
| rgareus | arguy: an easy way: just use jack_ringbuffer (and link against libjack for prototyping). or just copy its code. | 20:18 |
| rgareus | 1) write all incoming data into a ringbuffer. 1 sample at a time. check if it contains >= 480 samples. if so: read them to rnnoise_input_frame[] and go. | 20:19 |
| rgareus | 2) write results from rnnoise_output_frame[] into the output-ringbuffer. | 20:20 |
| rgareus | 3) if output-ringbuffer contains >= n_frames samples pop the them from the ringbuffer and write the to the plugin's output. | 20:21 |
| rgareus | jack_ringbuffer is a bit overkill here, since your case all is in sync. but it does the job just fine for prototying. | 20:22 |
| *** deva has quit IRC | 20:57 | |
| *** edo_pc has joined #lv2 | 21:04 | |
| *** yann-kaelig has quit IRC | 21:22 | |
| *** dsheeler has joined #lv2 | 21:32 | |
| arguy | I'm using 2 fifos one for the input and one for the output and they are in sync so what you are describing won't happen. And the output fifo is initialized with zeros so it will output zeros correctly the first frame. In fact I double checked that it works correctly as a delay line and it does work. Unless I'm totally wrong here It must be something I'm doing wrong with the library | 21:37 |
| arguy | But using a ring buffer is a more sane option yes. I'm just lazy | 21:39 |
| arguy | I saw a ringbuffer implementation in tuna.lv2 maybe I will look at that | 21:40 |
| rgareus | arguy: that's also used to decouple threads | 21:43 |
| rgareus | like jack-ringbuffer it's aimed as reading/writing being async. | 21:43 |
| rgareus | arguy: your fifos should be fine for the case at hand. | 21:44 |
| arguy | Thanks anyways rgareus! | 21:45 |
| rgareus | just the offset pointer will be different for input and output. | 21:45 |
| rgareus | arguy: and you're welcome. keep up the good work! | 21:51 |
| *** grejppi_ is now known as grejppi | 22:06 | |
| *** edo_pc has quit IRC | 22:17 | |
| *** HarryHaaren has quit IRC | 22:28 | |
| *** rncbc has quit IRC | 22:37 | |
| *** drobilla has quit IRC | 23:30 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!