Re: [LAD] Open Source to be or not to be?
[hermann meyer] However, this list here is the wrong place to discus that any further, I just hope that some people here get interested in such a approve (Tim you are more then welcome to join us), if, please join us at guitarix-develo...@lists.sourceforge.net Thank you kindly Hermann, I hope I'll be able to join you guys at a later date. In re circuit emulation, I have to concur with Fons: meaningful nonlinear full-circuit emulation (i.e. employing more than just a single isolated idealised nonlinear component) appears to be too demanding for realtime application on current hardware (and I think the problem doesn't lend itself well to parallelisation so the current trends in CPU progress won't help much) and if you stay linear I think you're better off with traditional optimised digital filter designs. Not to say it's not a great tool, but I see its value more in gaining insight than realtime processing. Cheers, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Open Source to be or not to be?
Am 30.06.2014 23:13, schrieb Stéphane Letz: Interesting discussion... ((-; It would be great if the corrected zita-rev1 Faust version goes back in the Faust distribution at some point…. Yes, it's in faust git now as well. http://sourceforge.net/p/faudiostream/code/ci/396bbc789811034dfb30f081a7d60aa2fb96d7e2/ ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Open Source to be or not to be?
Am 02.07.2014 11:18, schrieb Tim Goetze: [hermann meyer] However, this list here is the wrong place to discus that any further, I just hope that some people here get interested in such a approve (Tim you are more then welcome to join us), if, please join us at guitarix-develo...@lists.sourceforge.net Thank you kindly Hermann, I hope I'll be able to join you guys at a later date. In re circuit emulation, I have to concur with Fons: meaningful nonlinear full-circuit emulation (i.e. employing more than just a single isolated idealised nonlinear component) appears to be too demanding for realtime application on current hardware (and I think the problem doesn't lend itself well to parallelisation so the current trends in CPU progress won't help much) and if you stay linear I think you're better off with traditional optimised digital filter designs. Maybe true. Indeed we are not able to generate realtime capable source code direct from a (nonlinear) circuit schematic, it's to complex. A lot to resolve. But we work on it. Alone the build script for the jcm800pre takes 288 lines python, and a couple of optimization steps are needed to get it at least run with ~20%DSP load. But the result is indeed passable in terms of how it sounds lately. Clearly a picture from the beach isn't the beach. :-D regards hermann Not to say it's not a great tool, but I see its value more in gaining insight than realtime processing. Cheers, Tim ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Streaming AV/midi
On Wed, July 2, 2014 2:22 pm, Flávio Schiavoni wrote: Hi Patrick A first advice is to try some tool that works with multicast / broadcast addressing method to allow a one to many connection. It means to work with UDP because TCP can not do multicast or broadcast. So you can save some bandwidth. Since RTP is not a transport protocol but a kind of application protocol over UDP, a tool RTP based can be used. If I'm not wrong, Icecast works with TCP. I dunno if it can be configured. Thanks for that tip. I am currently looking at ffserver with ffmpeg. IIUC it can support RTP too so that might be a good way forward. I have it running on my device and I am testing the stream/codec combinations at the moment. Gotta hand it to the ffmpeg devs for keeping keeping pace with the market. Some questions: - Do you need to sync audio / video / MIDI? Not really sample accurate but 2000ms is the limit for lag. - What is your audio / video / MIDI source? File? Cam? /dev/graphics/fb0 + external BT microphone - How will it be used on the receiver? Monitor? Projector? If I use ffserver the output will be displayed as a video stream at the application level. Pure Data can send audio / midi / video. I will look into PD if ffserver is unable to get the job done. If I'm not wrong, GStreamer can do it too. Cheers Schiavoni Em 01-07-2014 06:34, Patrick Shirkey escreveu: Hi, Does anyone have a suggestion for open source solutions to enable streaming AV/midi to multiple ARM mobile devices with a one to many network configuration? I am looking at the following options: 1: ffmpeg streaming server 2: icecast with netjack 3: netjack There are some limitations. 1: Server is a mobile device with dual core ARM chipset 2: Wifi connectivity with 20Mb/s total uplink from master server. An ideal implementation would allow 20 client devices to receive the audio stream in close to realtime. Upto 100ms delay would be acceptable. I'm weighing up the benefits from using FFMPEG to stream all the data compared to a 32/64bit icecast stream with additional midi triggering for visual data located on the client app. - FFMPEG has the benefit of removing all trigger events but costs a lot in terms of bandwidth/power consumption. - Icecast is very good at serving audio but iiuc does not support video/midi - Netjack can potentially do all three but is not well tested on a mobile platform. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
