>
> Message: 17
> Date: Mon, 30 Jun 2014 15:32:37 +0000
> From: Fons Adriaensen <fons(a)linuxaudio.org>
> To: linux-audio-dev(a)lists.linuxaudio.org
> Subject: Re: [LAD] Open Source to be or not to be?
> Message-ID: <20140630153237.GB29991(a)linuxaudio.org>
> Content-Type: text/plain; charset=us-ascii
>
> On Mon, Jun 30, 2014 at 04:02:20PM +0200, hermann meyer wrote:
>
>> PLease, Fons, if you found more Bugs, or have any issue with the way
>> we implement parts of your work, let me know. I'm all open !
>
> The four T60 controls are supposed to be log as well.
> And please get rid of that silly little slider named
> 'Freq X'.
>
>
> Another matter: starting guitarix without Jack running produces
> an empty black 'Jack Starter' window. No matter what I do next
> will crash X11.
>
>
> --
> FA
>
> A world of exhaustive, reliable metadata would be an utopia.
> It's also a pipe-dream, founded on self-delusion, nerd hubris
> and hysterically inflated market opportunities. (Cory Doctorow)
>
>
Interesting discussion... ((-;
It would be great if the corrected zita-rev1 Faust version goes back in the Faust distribution at some point….
Fons, you know what? the Faust zita-rev1 version (still old one of course..) now even runs in the web, automagically compiled in asm.js (http://asmjs.org) using latest faust2 git version and running at acceptable speed in recent browsers like Firefox or Chrome (still some issues here…) :
http://faust.grame.fr/www/zita_rev1.html
Is it interesting? a way to promote open-source DSP code? who knows...
Stéphane
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
On Wed, July 2, 2014 5:16 am, drew Roberts wrote:
> On Tue, Jul 1, 2014 at 11:34 AM, Patrick Shirkey
> <pshirkey(a)boosthardware.com
>> wrote:
>
>>
>> On Tue, July 1, 2014 10:41 pm, drew Roberts wrote:
>> > On Tue, Jul 1, 2014 at 5:34 AM, Patrick Shirkey
>> > <pshirkey(a)boosthardware.com>
>> > wrote:
>> >
>> >> 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?
>> >>
>> >>
>> >> - Icecast is very good at serving audio but iiuc does not support
>> >> video/midi
>> >>
>> >>
>> > IIRC, icecast2 can stream video. Never thought to try midi.
>> >
>>
>> According to the icecast folks the latency and sync for a standard
>> stream
>> can get out to 10 seconds which is outside of my range. I could probably
>> handle upto 2000ms but less than 1000ms is preferable.
>>
>
> What are you thinking of using to do the "shouting"? IIRC, we were using
> vlc.
>
For this project I will probably have to build a custom tool that uses
ffmpeg for transcoding. VLC might be a good place to start but the
codebase is pretty large if I have to customise it so it's probably faster
to start from scratch.
> Concerning the sync, if you mean audio with video, what we were doing did
> not require synced audio.
>
This project probably doesn't require realtime sample accurate sync but
the latency should be within 2000ms between audio and video streams and
also between master/client. Latency should be as low as possible with a
balance between cpuload and bandwidth management.
Has anyone benchmarked realtime transcoding on dual core arm devices with
ffmpeg?
>>
>> Anyway I will give icecast with video a test run before I rule it out.
>>
>>
>> --
>> Patrick Shirkey
>> Boost Hardware Ltd
>> __________________
>>
>
> all the best,
>
> drew
> --
> http://freemusicpush.blogspot.com/
>
--
Patrick Shirkey
Boost Hardware Ltd
