| *** YuriW has quit IRC | 00:00 | |
| *** Yruama_Lairba has quit IRC | 01:03 | |
| *** ArturShaik has joined #kxstudio | 01:33 | |
| *** designbybeck has joined #kxstudio | 01:59 | |
| *** designbybeck has quit IRC | 02:15 | |
| *** HeyCitizen has joined #kxstudio | 02:47 | |
| *** ArturShaik has quit IRC | 03:23 | |
| *** ArturShaik has joined #kxstudio | 03:40 | |
| *** falktx` has joined #kxstudio | 03:57 | |
| *** falktx has quit IRC | 04:00 | |
| *** therealthelonius has quit IRC | 04:37 | |
| *** therealthelonius has joined #kxstudio | 04:37 | |
| *** wolftune has quit IRC | 04:47 | |
| *** rghvdberg has joined #kxstudio | 06:52 | |
| *** jim has quit IRC | 07:11 | |
| *** jim has joined #kxstudio | 07:13 | |
| *** sakrecoer has quit IRC | 08:26 | |
| *** DoverMo has joined #kxstudio | 08:32 | |
| *** DoverMo has quit IRC | 08:37 | |
| *** dromer has joined #kxstudio | 09:08 | |
| *** dreamer has quit IRC | 09:08 | |
| *** dromer is now known as dreamer | 09:08 | |
| *** dreamer has joined #kxstudio | 09:08 | |
| *** olinuxx has joined #kxstudio | 09:21 | |
| *** olinuxx has joined #kxstudio | 09:21 | |
| rgareus | FergusL: aah there you are :) you left rather quicky yesterday | 09:50 |
|---|---|---|
| rgareus | FergusL: re "documentation on [..] like relationship of sampling rate with block size, latency, perceived latency, feeding data to a DAC etc" | 09:50 |
| rgareus | FergusL: the first is easy latency [s] = block-size [samples] / sample-rate [samples / seconds] | 09:50 |
| rgareus | FergusL: perceived latency, unless you mean psychoacoustics: http://manual.ardour.org/synchronization/latency-and-latency-compensation/ (elaborates on round-trip and latency sources) | 09:51 |
| rgareus | FergusL: feeding data to a DAC.. that's vague. On an electrical level? that'll take full semester to explain :) just using a DAC that's already on some PC bus ? | 09:52 |
| FergusL | rgareus: thanks for the rather detailed answer! | 10:25 |
| FergusL | in the meantime I made myself a cute LibreOffice Calc sheet which calculates latency and other things | 10:25 |
| FergusL | that ardour link was interesting too, I liked the note about church organist and latency compensation haha | 10:31 |
| rgareus | FergusL: that's only half joking :) | 10:34 |
| FergusL | I could get that, I believe! being pretty far from the location of the sound production and also the time needed for the mechanical parts to activate and produce sound | 10:35 |
| rgareus | the mechanics for those organs do have a *mechanical* latency of often > 100ms and then until the air starts resonating some HUGE pipes can be up to half a second | 10:35 |
| rgareus | and then the crowd in the church starts.. anoter second later with about 2 seconds jitter :) | 10:36 |
| FergusL | I was at St Merry church few weeks ago and singer performed along with the organ, I couldn't tell where the organist was but it made a nice surround effect | 10:37 |
| rgareus | the point is that in a many of cases users screaming "I need extreme low latency" is bullshit. | 10:41 |
| rgareus | granted it's more complicated - esp with headphone monitoring. but well. | 10:41 |
| rgareus | FergusL: is there a particula thing that you're working on, or just out of general interest? | 10:42 |
| FergusL | what's extreme low? <1ms ? for all embedded setups I'm planning on working on i'm aiming at <= 6ms | 10:43 |
| rgareus | FergusL: as rule of thumb <= 10ms round-trip is fine. | 10:43 |
| FergusL | hm last time in #moddevices I asked a few questions about kernel hacking and linux setup on Mod, cause I'm going to start working on lower power, lower performance things | 10:44 |
| rgareus | that's ~ 3 meters in air. | 10:44 |
| FergusL | (more like the Bela Platform if you happen to know about it) | 10:44 |
| rgareus | yeah, heard about it, didn't get my hands on it, yet | 10:45 |
| rgareus | FergusL: in that case limiting factor will be bus and upwards (driver, kernel-scheduler, user-space software) | 10:46 |
| FergusL | and very precisely all those questions I have arise from wondering how to handle playing the sound through the DAC *and* processing the next block at the same time in a single core context | 10:46 |
| FergusL | I know about DMA, at the much lower level, that helps with these asynchronous tasks and I also know it's used in embedded platforms | 10:47 |
| rgareus | FergusL: write n samples ; read n-samples ; process those samples [ wait until you can write and read N samples] repeat; | 10:50 |
| rgareus | it's not async | 10:50 |
| rgareus | the "wait until" is usually sleep wake up on IRQ | 10:51 |
| FergusL | and also well below human ear perception of a dropout ? | 10:51 |
| rghvdberg | https://soundcloud.com/rghvdberg/rghvdberg-today-is-not-that-day-osc-88 | 10:51 |
| LAbot` | Title: rghvdberg - Today Is Not That Day [OSC 88] by Rob van den Berg | Free Listening on SoundCloud (at soundcloud.com) | 10:51 |
| rghvdberg | done with it ... next song is gonna be a happy one .. this is bringing me down | 10:52 |
| rghvdberg | ;-) | 10:52 |
| rgareus | FergusL: dropout: there are 2 aspects to it: audible artifacts since the signal goes to 0 when you don't feed more data. | 10:53 |
| rgareus | FergusL: if you were not playing silence it'll be a click high-frequency. non-zero to zero in one sample | 10:53 |
| rgareus | FergusL: often more important is timing however. all processing is late and it gradually drifts. | 10:54 |
| FergusL | yes! actually that was one of the tests I've made yesterday haha, trying cutting single samples, in Pd and then in audacity | 10:54 |
| rgareus | FergusL: the latter part is not important if you only play back. but any in -> process -> out will be problematic reverbs are an example. | 10:55 |
| rgareus | or recordings won't align anymore | 10:56 |
| *** Yruama_Lairba has joined #kxstudio | 10:56 | |
| rgareus | e.g record 1 sec of guitar @ 48K -> 48000 samples; rewind record 1 sec of drums @ 48K [dropout] -> less than 48000 samples, short by the dropout-duration. | 10:57 |
| rgareus | things don't align anymore | 10:57 |
| rgareus | FergusL: DMA is always IRQ triggered. | 10:58 |
| rgareus | FergusL: there's a callback when the trasaction is complete | 10:58 |
| rgareus | the kernel alsa driver abstracts that nicely, however | 10:59 |
| rgareus | FergusL: I'm not sure how low-level you want to go: for debugging the mod-driver I've written https://github.com/moddevices/mod-alsa-test | 11:00 |
| rgareus | mainly useful exercise DMA transfers and conveniently set various parameters | 11:01 |
| FergusL | rgareus: ok really cool! I'll look at that | 11:02 |
| rgareus | FergusL: one thing that you notice https://github.com/moddevices/mod-alsa-test/blob/master/mod-alsa-test.c#L327 << "start processing" | 11:03 |
| rgareus | FergusL: first write N samples | 11:03 |
| rgareus | FergusL: jack does the same. you pre-seed the output before reading | 11:03 |
| rgareus | it's not [ read -> process -> write ] but [ write -> read -> process ] | 11:04 |
| rgareus | FergusL: that may explain the single-core synchronous part | 11:04 |
| rgareus | FergusL: then again, you could just use jack and forget about all of that :) | 11:06 |
| rgareus | mod-alsa-test isn't complete. it does not actually do something with the samples and also properly supports MOD's SND_PCM_FORMAT_S24_BE | 11:07 |
| rgareus | uhm _LE | 11:08 |
| rgareus | but for debugging driver wakeup and DMA timing I didn't care for actual audio. | 11:09 |
| FergusL | http://www.adeneo-embedded.com/content/download/1801/23674/file/Real-time%20Audio%20on%20Embedded%20Linux.pdf I found that as well, quite old and very different hardware but it suggests non-rt non-jack can provide decent latencies | 11:09 |
| FergusL | the platform is 600MHz single core! | 11:09 |
| rgareus | well, you can do that stuff on a 1MHz Arduino, too | 11:10 |
| rgareus | the limiting factor is processing | 11:10 |
| rgareus | FergusL: that's a good overview | 11:13 |
| rgareus | even has a reference to cyclictest | 11:13 |
| rgareus | FergusL: rt-kernel is only needed if there are lots of other things going on that can prevent the audio DMA irq to be handled in time. | 11:17 |
| rgareus | USB is also a good candidate. normally all usb devices are equal. | 11:18 |
| rgareus | but you do want a usb-soundcard to have priority over a usb-mouse.. | 11:19 |
| FergusL | I see, yes, makes sense, that's why I want to keep the software stack at a minimum, hence also why OpenWRT seemed interesting, it doesn't have any of the typical desktop services running etc... | 11:19 |
| rgareus | indeed, though that part is user-space. and even vanilla kernel have scheduling policies for those. | 11:21 |
| rgareus | still, switching tasks takes time. | 11:21 |
| FergusL | recently acquired hardware to test regarding all of those ideas: http://bz.seeedstudio.com/depot/LinkIt-Smart-7688-p-2573.html?cPath=122_142 + its 24 bit audio in/out breakout | 11:22 |
| rgareus | FergusL: cyclictest is really a good middle-ground to start. cyclictest -m -S -d0 -p80 # keep it running for a while | 11:24 |
| rgareus | FergusL: the last number in line is the worst-case (usec) | 11:24 |
| rgareus | FergusL: that's the time it takes for the scheduler to switch between two tasks | 11:24 |
| rgareus | and if the kernel-scheduler already has - 1000usec == 1ms as worst case, you can't have latency lower than that. | 11:25 |
| rgareus | if that number gets large -> use a rt-kernel. if it stays reliably low, kernel is good in general. (not taking the actual audio-driver into account) | 11:27 |
| rgareus | next step is to keep cyclictest running and start audio playback to check the driver. that's where the mod fell over | 11:28 |
| FergusL | rgareus: actually where did you spot cyclictest? in the pdf I linked to? | 11:28 |
| rgareus | FergusL: on most distros it comes with the rt-tests package | 11:28 |
| rgareus | https://rt.wiki.kernel.org/index.php/Cyclictest | 11:28 |
| LAbot` | Title: Cyclictest - RTwiki (at rt.wiki.kernel.org) | 11:28 |
| rgareus | ^^ has link to source etc | 11:29 |
| FergusL | very afraid openwrt won't have it :| I'll check... actually I have those boards just next to be but I'm still supposed to write my Masters 2 thesis so I have only just looked at it! haven't taken the take to start it | 11:30 |
| FergusL | thanks | 11:30 |
| rgareus | FergusL: the "Real-Time Audio..." slides mentioned it | 11:31 |
| FergusL | saw it now | 11:31 |
| rgareus | but regardless it's a very useful tool | 11:32 |
| FergusL | ok thanks! at least that tells me the first thing I'll have to do to get an idea of the expectations I should have | 11:34 |
| FergusL | also, can you confirm by rt kernel you mean a kernel patched for specific hardware? I remember it was very specific to Allwinner A20 when I tried the rt patchset, also rt on OpenWRT is of interest in the networking industry but not much investigated | 11:35 |
| rgareus | only sunxi is special. | 11:39 |
| rgareus | the rt-patch is for vanilla linux which runs just fine on ARM. | 11:39 |
| rgareus | there's no specific hardware patch - except that weird sunxi abomination (they have lot of custom hardware with crappy drivers that won't be accepted upstream, so they forked it) | 11:40 |
| FergusL | isn't Allwinner doing all that crap in the first place? gpl issues etc | 11:42 |
| FergusL | alright, back to all that later, really got to focus on writing :) | 11:46 |
| *** olinuxx has quit IRC | 11:47 | |
| *** bill-auger has quit IRC | 11:57 | |
| *** bill-auger has joined #kxstudio | 11:57 | |
| *** olinuxx has joined #kxstudio | 12:00 | |
| *** stuartcnz has quit IRC | 12:05 | |
| rgareus | rghvdberg: today's indeed not that day! | 12:19 |
| rgareus | rghvdberg: your profile pic on SC pictures you in front or a mic. Do any of your tracks have vocals? | 12:20 |
| *** stuartcnz has joined #kxstudio | 12:21 | |
| *** falktx|work has joined #kxstudio | 13:16 | |
| rghvdberg | nope, don't even have a microphone | 13:20 |
| rghvdberg | I sing backing vocals with my live bands | 13:21 |
| rghvdberg | I only make songs for the one synth challenge ... I'm weird | 13:22 |
| FergusL | rgareus: hm have you used the CROSS_COMPILE make flag in rt-tests? seems it's ignored | 14:40 |
| FergusL | oh, wait, other issue I hadn't noticed | 14:42 |
| *** YuriW has joined #kxstudio | 15:05 | |
| *** wolftune has joined #kxstudio | 15:21 | |
| *** falktx|work has quit IRC | 15:28 | |
| *** ArturShaik has quit IRC | 15:36 | |
| *** wolftune has quit IRC | 15:45 | |
| *** GrusGrus has joined #kxstudio | 15:46 | |
| *** wolftune has joined #kxstudio | 15:54 | |
| *** GrusGrus has quit IRC | 15:59 | |
| FergusL | rgareus: seems I get indeed some errors to cross compile to the platform I'm using | 16:16 |
| FergusL | http://paste.leloop.org/?a8b896d405438951#1KQLtOsXg0ujqAxlef3OgBeRFpCm8NTLEkptWfKwDWg= it's an error with a function already declared, this block is inside an #ifdef __UCLIBC__... I found a hack on a chinese forum that just "#ifdef 0" haha.. haven't tested | 16:19 |
| FergusL | juste pasting that here in case you want to have a look, and thanks for all your previous help! | 16:20 |
| *** BitPuffin has joined #kxstudio | 16:38 | |
| *** rghvdberg has quit IRC | 16:44 | |
| *** sirriffsalot has joined #kxstudio | 16:45 | |
| *** falktx|work has joined #kxstudio | 18:06 | |
| *** olinuxx has quit IRC | 18:57 | |
| *** jablo has joined #kxstudio | 19:12 | |
| *** BitPuffin has quit IRC | 19:26 | |
| *** falktx|work has quit IRC | 19:58 | |
| *** rncbc has joined #kxstudio | 19:59 | |
| *** bill-auger_ has joined #kxstudio | 21:22 | |
| *** bill-auger has quit IRC | 21:22 | |
| *** wolftune has quit IRC | 21:31 | |
| *** prettyvanilla_ has joined #kxstudio | 21:37 | |
| *** wolftune has joined #kxstudio | 21:38 | |
| *** prettyvanilla has quit IRC | 21:45 | |
| *** daeavelwyn has quit IRC | 21:45 | |
| *** jablo has quit IRC | 21:46 | |
| *** olinuxx has joined #kxstudio | 21:59 | |
| *** olinuxx has joined #kxstudio | 21:59 | |
| *** YuriW has quit IRC | 22:23 | |
| *** wolftune has quit IRC | 23:20 | |
| *** wolftune has joined #kxstudio | 23:23 | |
Generated by irclog2html.py 2.13.0 by Marius Gedminas - find it at mg.pov.lt!