18 Jul
2015
18 Jul
'15
10:21 p.m.
Hi there,
I am wanting to run jackd on low resourced/power embedded systems
(running Linux).
When I run jackd on these systems it tries to lock down way to much
memory ... much more then is available.
Is the amount of memory locked down by jackd configurable ? Or is it an
operating system set thing ?
Does anyone have any constructive ideas or suggestions for running jackd
on these low resource embedded systems ?
thanks
Matt
19 Jul
19 Jul
3:47 a.m.
I don't know if it's ok to change it, but perhaps limiting tmpfs
in /etc/fstab by size= and limiting memlock in /etc/security/limits.conf
has something to do with it and could be changed.
Assumed nobody with the needed knowledge should reply soon, it might be
worth to use "memlock", "ulimit" etc. as search terms for Internet
research.
By default tmpfs takes half of the RAM and a default real-time
limits.conf comes with an unlimited memlock.
Attention, that are just shots in the dark!
4:50 a.m.
I had the same issue a while back. I think that I got away by reducing
the maximal
amount of ports.
man jackd (jack1)
------------------------------------------------------------------------------------------------------
-p, --port-max n
Set the maximum number of ports the JACK server can
manage. The
default value is 256.
------------------------------------------------------------------------------------------------------
5:06 a.m.
Hi there,
That is a good start, however I found that if I reduce to say 4 ports,
it still requests about 13MB ... the free space on this embedded system
is about half that ! My understanding is that shm is trying to lock down
enough memory for now and the future ... however it may be excessive ?!?
If you consider that @ 48kHz, 6ms latency, we are talking about
kilobytes of audio data - maximum !
So conceivably, we should be able to operate with limited memory
resources of megabytes, rather then tens of megabytes.
I understand that the bigger concept is to keep as much in memory to
avoid future paging ... still searching ...
Matt
On 19/07/15 19:50, Hanspeter Portner wrote:
I had the same issue a while back. I think that I got
away by reducing
the maximal
amount of ports.
man jackd (jack1)
------------------------------------------------------------------------------------------------------
-p, --port-max n
Set the maximum number of ports the JACK server can
manage. The
default value is 256.
------------------------------------------------------------------------------------------------------
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
5:13 a.m.
On Sun, Jul 19, 2015 at 01:19:19PM +1000, Matt Flax wrote:
When I run jackd on these systems it tries to lock
down way to much
memory ... much more then is available.
It might be worth checking jackd1 vs. jackd2 memory footprint.
My gut feeling is that jackd1's is smaller, but you'd need to actually
measure it.
And of course the ports flag that Hans-Peter mentioned.
Cheers
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
8:40 a.m.
Yes you are correct.
I can run jackd1 on this embedded system with very limited resources.
Thanks for the suggestion.
Matt
On 19/07/15 20:13, Adrian Knoth wrote:
On Sun, Jul 19, 2015 at 01:19:19PM +1000, Matt Flax
wrote:
When I run jackd on these systems it tries to
lock down way to much
memory ... much more then is available.
It might be worth checking jackd1 vs.
jackd2 memory footprint.
My gut feeling is that jackd1's is smaller, but you'd need to actually
measure it.
And of course the ports flag that Hans-Peter mentioned.
Cheers
3:34 p.m.
On Sun, Jul 19, 2015 at 2:40 PM, Matt Flax <flatmax(a)flatmax.org> wrote:
I can run jackd1 on this embedded system with very
limited resources.
I'm interested in why you're choosing JACK instead of "just" using the
native (I'll presume ALSA) API for your audio backend? Not that I'm opposed
to JACK - its a wonderful way of connecting audio applications in
innovative and professional ways - but that doesn't mean its the best fit
for every use case.
Cheers, -Harry
--
http://www.openavproductions.com
7:16 p.m.
Thanks for the question.
Jack has network audio working well - this is a big bonus, as on these
limited systems you can't do too much audio processing as they have
limited resources and power.
Jack also uses LPC based compression over the network - which is
lossless. That is normally a minimum of 2 times compression.
Can you tell me how you would approach this ? I understand that by
getting rid of Jack, you would free up a large amount of already limited
memory on these devices ... but how would you do network audio in a
standard fashion ?
Matt
On 20/07/15 06:34, Harry van Haaren wrote:
On Sun, Jul 19, 2015 at 2:40 PM, Matt Flax
<flatmax(a)flatmax.org
<mailto:flatmax@flatmax.org>> wrote:
I can run jackd1 on this embedded system with very limited resources.
I'm interested in why you're choosing JACK instead of "just" using the
native (I'll presume ALSA) API for your audio backend? Not that I'm
opposed to JACK - its a wonderful way of connecting audio applications
in innovative and professional ways - but that doesn't mean its the
best fit for every use case.
Cheers, -Harry
--
http://www.openavproductions.com
20 Jul
20 Jul
7:15 a.m.
On Sun, Jul 19, 2015 at 8:16 PM, Matt Flax <flatmax(a)flatmax.org> wrote:
Thanks for the question.
Jack has network audio working well - this is a big bonus, as on these
limited systems you can't do too much audio processing as they have limited
resources and power.
Jack also uses LPC based compression over the network - which is lossless.
That is normally a minimum of 2 times compression.
Can you tell me how you would approach this ? I understand that by getting
rid of Jack, you would free up a large amount of already limited memory on
these devices ... but how would you do network audio in a standard fashion ?
There are no standards for network audio, just so we're clear. Or more
precisely, there are so many "standards" that there are no standards.
7:48 a.m.
On 20/07/15 22:15, Paul Davis wrote:
On Sun, Jul 19, 2015 at 8:16 PM, Matt Flax
<flatmax(a)flatmax.org> wrote:
Thats the point, it is more about what is useful for software to
interface, rather then what protocol to use. Well mostly anyway ...
Matt
Thanks for the question.
Jack has network audio working well - this is a big bonus, as on these
limited systems you can't do too much audio processing as they have limited
resources and power.
Jack also uses LPC based compression over the network - which is lossless.
That is normally a minimum of 2 times compression.
Can you tell me how you would approach this ? I understand that by getting
rid of Jack, you would free up a large amount of already limited memory on
these devices ... but how would you do network audio in a standard fashion ?
There
are no standards for network audio, just so we're clear. Or more
precisely, there are so many "standards" that there are no standards.
10:51 a.m.
Hi,
Sorry for the thread hijacking, bu AVB is'nt a standard ?
https://en.wikipedia.org/wiki/Audio_Video_Bridging
wargreen
On 20/07/2015 14:15, Paul Davis wrote:
On Sun, Jul 19, 2015 at 8:16 PM, Matt Flax
<flatmax(a)flatmax.org> wrote:
Thanks for the question.
Jack has network audio working well - this is a big bonus, as on these
limited systems you can't do too much audio processing as they have limited
resources and power.
Jack also uses LPC based compression over the network - which is lossless.
That is normally a minimum of 2 times compression.
Can you tell me how you would approach this ? I understand that by getting
rid of Jack, you would free up a large amount of already limited memory on
these devices ... but how would you do network audio in a standard fashion ?
There
are no standards for network audio, just so we're clear. Or more
precisely, there are so many "standards" that there are no standards.
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org
10:55 a.m.
On Mon, Jul 20, 2015 at 11:51 AM, Wargreen <wargreen(a)lebib.org> wrote:
Hi,
Sorry for the thread hijacking, bu AVB is'nt a standard ?
https://en.wikipedia.org/wiki/Audio_Video_Bridging
> precisely, there are so many "standards"
that there are no standards.
<obXKCD>
https://xkcd.com/927/
</obXKCD>
10:58 a.m.
On 20 Jul 2015, at 16:55, Paul Davis <paul(a)linuxaudiosystems.com> wrote:
On Mon, Jul 20, 2015 at 11:51 AM, Wargreen <wargreen(a)lebib.org> wrote:
https://en.wikipedia.org/wiki/Comparison_of_audio_network_protocols
Hi,
Sorry for the thread hijacking, bu AVB is'nt a standard ?
https://en.wikipedia.org/wiki/Audio_Video_Bridging
> precisely, there are so many
"standards" that there are no standards.
<obXKCD>
https://xkcd.com/927/
</obXKCD>
7:54 p.m.
The standard used by netjack can change, if it must :)
Does anyone know of a list of network audio software which shows usage
popularity by developer usage ? ... perhaps this is the more poignant
question ?
I would assume there is a list of proprietary and free options.
The list would have to include netjack and chromecast and others ...
Matt
On 21/07/15 01:57, Steve Harris wrote:
On 20 Jul 2015, at 16:55, Paul Davis
<paul(a)linuxaudiosystems.com> wrote:
On Mon, Jul 20, 2015 at 11:51 AM, Wargreen
<wargreen(a)lebib.org> wrote:
https://en.wikipedia.org/wiki/Comparison_of_audio_network_protocols
_______________________________________________
Jack-Devel mailing list
Jack-Devel(a)lists.jackaudio.org
http://lists.jackaudio.org/listinfo.cgi/jack-devel-jackaudio.org Hi,
Sorry for the thread hijacking, bu AVB is'nt a standard ?
https://en.wikipedia.org/wiki/Audio_Video_Bridging
> precisely, there are so many "standards" that there are no standards.
<obXKCD>
https://xkcd.com/927/
</obXKCD>
21 Jul
21 Jul
4:25 a.m.
On Tue, Jul 21, 2015 at 10:54:54AM +1000, Matt Flax wrote:
Does anyone know of a list of network audio software
which shows
usage popularity by developer usage ? ... perhaps this is the more
poignant question ?
By developer usage? That's a funny metric. ;)
Future-proof should be AES67, it's the designated "Let's harmonise it
once and for all" protocol. It recently gained some market adoption,
even the Dante folks announced AES67-compatible firmware.
Cheers
--
mail: adi(a)thur.de http://adi.thur.de PGP/GPG: key via keyserver
3195
days inactive
3198
days old
jackaudio@lists.linuxaudio.org
14 comments
8 participants
participants (8)
-
Adrian Knoth -
Hanspeter Portner -
Harry van Haaren -
Matt Flax -
Paul Davis -
Ralf Mardorf -
Steve Harris -
Wargreen