Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

2017-12-10 Thread Markus Seeber
On 12/10/2017 09:37 PM, Paul Davis wrote:
> On Sun, Dec 10, 2017 at 3:26 PM, Markus Seeber <
> markus.see...@spectralbird.de> wrote:
>
>> ​You can still statically link for example with FLTK
>>
> ​You still need to ensure that the host can integrate with FLTK (or any
> other toolkit's) event loop. Without some explicit awareness, events etc.
> will never be delivered to the non-host toolkit.​
>
>
>
>> and derivatives or roll your
>> own. On Windows I think Steinberg even provides a GUI toolkit for VST
>> plugins if
>>
> ​Not in any effective form. Their old version (more than a decade old) was
> based on *Motif* for X Window. There's a newer attempt at this, but it no
> notable benefits unless you wrote the host using the same thing, which is
> essentially impossible because of it's limited scope. ​
>
>
>
>> I remember correctly? Or go plain ImGui or plain OpenGL or whatever suits?
>>
>> Maybe robin can give better recommendations since he seems to have done
>> some work
>> on lv2 GUIs. (maybe see https://github.com/x42/robtk )
>>
> ​robtk is probably one of the most obvious answers, but even robin can
> identify some drawbacks.
>
> the thing is that on other platforms, there's a single event loop that all
> possible toolkits connect to. on Linux (X Window (and probably Wayland
> too)), this isn't true. Qt has done work to use the same glib-based event
> loop as GTK but this isn't a general solution. ​ On Windows or MacOS, it
> makes no difference what toolkit the host and plugin use, because
> everything is inevitably going to get routed through the same event loop
> (and redraw cycle). On Linux this is not true, and it's the root of most of
> these issues with plugins.
>
>
Hm, I did not think about that hard enough, honestly. Then again this makes
me want to explore the idea of a plugin GUIs separately from the DAW process.
This is not a new idea, but has it already been implemented and explored in 
detail,
apart from the obvious translation of MIDI/OSC from/to track automation?
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

2017-12-10 Thread Markus Seeber
On 12/10/2017 08:43 PM, Gordonjcp wrote:
> On Sun, Dec 10, 2017 at 08:37:08PM +0100, Markus Seeber wrote:
>> On 12/10/2017 03:31 PM, Paul Davis wrote:
>>> On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
>>> markus.see...@spectralbird.de> wrote:
>>>
>>>> ​
>>>> Just employ static linking when sensible.
>>> ​unortunately, several large toolkits of various types make this impossible
>>> because they themselves use dynamic (runtime-driven) loading of shared
>>> objects. GTK (and its dependency stack) is a particular offender there, but
>>> I believe the same is true of Qt. You can't statically link against this
>>> type of toolkit if your goal is to end up with a self-contained binary. the
>>> g* stack has made a few improvements in this area in recent years, but
>>> AFAIK it still isn't possible to build a self-contained binary. JUCE
>>> differs from this, I believe.​
>>> ​
>> That is exactly the problem with plugins. At the same time I'd say:
>> "Don't use these GUI librarys for plugins and do not load any plugin that 
>> exports these symbols."
>> and be done with it, let offensive software die. In my eyes writing a plugin 
>> GUI
>> in GTK/Qt is very bad practice for exactly these reasons.
> So what would you write it in instead?
>
You can still statically link for example with FLTK and derivatives or roll your
own. On Windows I think Steinberg even provides a GUI toolkit for VST plugins if
I remember correctly? Or go plain ImGui or plain OpenGL or whatever suits?

Maybe robin can give better recommendations since he seems to have done some 
work
on lv2 GUIs. (maybe see https://github.com/x42/robtk )

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

2017-12-10 Thread Markus Seeber
On 12/10/2017 03:31 PM, Paul Davis wrote:
> On Sun, Dec 10, 2017 at 5:51 AM, Markus Seeber <
> markus.see...@spectralbird.de> wrote:
>
>> ​
>> Just employ static linking when sensible.
>
> ​unortunately, several large toolkits of various types make this impossible
> because they themselves use dynamic (runtime-driven) loading of shared
> objects. GTK (and its dependency stack) is a particular offender there, but
> I believe the same is true of Qt. You can't statically link against this
> type of toolkit if your goal is to end up with a self-contained binary. the
> g* stack has made a few improvements in this area in recent years, but
> AFAIK it still isn't possible to build a self-contained binary. JUCE
> differs from this, I believe.​
> ​

That is exactly the problem with plugins. At the same time I'd say:
"Don't use these GUI librarys for plugins and do not load any plugin that 
exports these symbols."
and be done with it, let offensive software die. In my eyes writing a plugin GUI
in GTK/Qt is very bad practice for exactly these reasons.

Or even better: Do not run the plugin GUI inside the DAW procces. Surely this 
comes with
it's own challenges as plugin developers now have to develop IPC mechanisms 
inside their
plugins and a way to negotiate how the GUI process connects to the plugin DSP 
part etc... .

Or go the JACK way, but for a DAW we already know that this has it's own 
problems.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

2017-12-10 Thread Markus Seeber
On 12/10/2017 12:14 PM, Filipe Coelho wrote:
> On 10.12.2017 11:51, Markus Seeber wrote:
>> On 12/09/2017 02:32 PM, nils wrote:
>>> Bottom line: It turned out the Windows way of shipping all or most
>>> libs with the program is a really good way to compatibility.
>> Just employ static linking when sensible.
>>
>> ...
>>
>> The current way of bundling shared libraries with the application ist just a 
>> dirty workaround
>> for Problems that combines the worst parts of static and dynamic linking,
>> introduces bloat and solves problems that are mostly caused by employing 
>> dynamic
>> linking in the first place.
>
> This is not related to Linux, but since someone already mentioned Windows.. I 
> have bad news for you.
> See 
> https://forum.juce.com/t/important-breaking-change-juce-will-now-use-dynamic-linking-for-the-windows-runtime-by-default/25276
>
> Basically, with the latest updates, you can only load a maximum of 64 
> statically built plugins in a Windows DAW.
>

But this only concerns the windows runtime library, right? Everything else can 
still be linked statically.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Forgive me, for I have sinned, or: toss your Macintosh, as fast and wide as you can.

2017-12-10 Thread Markus Seeber
On 12/09/2017 02:32 PM, nils wrote:
> Yes, that is possible and I wholeheartly lobby for that because library
> bugs and mismatches are common and could be avoided.
>
> Ardour does it and I do it in my own programs as well, or at least will
> if properly released. If you can copy a library into your source tree
> (Python in my case) why would depend to the external ecosystem?
>
> Some Linux distributions  (mostly very small and unknown though) do it
> already but the "way of forefathers", the shared library, is still stuck
> in peoples head.
No the "way of forefathers" was static linking.
>
> Bottom line: It turned out the Windows way of shipping all or most
> libs with the program is a really good way to compatibility.

Just employ static linking when sensible. There are less ways a linker can 
screw that up
during runtime and your application size will be even smaller since we have 
link time
optimization these days, startup time will be faster and run time may be faster.
Sure, if LGPL licensed libraries are used, this may be impossible but from a 
technical
standpoind dynamic linking for self containing application bundles does not make
sense unless you actually need to link dynamically (e.g. license requirements, 
plugins etc.).

The current way of bundling shared libraries with the application ist just a 
dirty workaround
for Problems that combines the worst parts of static and dynamic linking,
introduces bloat and solves problems that are mostly caused by employing dynamic
linking in the first place.

Yes I understand why people do it, yes it works and yes it solves social and 
resource problems
so that people can move on. But the real technical problem is not solved.

>
> On 12/09/2017 02:24 PM, Louigi Verona wrote:
>> This is a good point, Fons.
>>
>> On Windows it is typical to bundle a program with stable libraries and
>> dependencies. Is this strategy thinkable on FLOSS systems?
>>
>>
>>
>>
>>
>>
>> ___
>> Linux-audio-dev mailing list
>> Linux-audio-dev@lists.linuxaudio.org
>> https://lists.linuxaudio.org/listinfo/linux-audio-dev
> ___
> Linux-audio-dev mailing list
> Linux-audio-dev@lists.linuxaudio.org
> https://lists.linuxaudio.org/listinfo/linux-audio-dev

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
https://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] aBLETON lINK

2016-09-23 Thread Markus Seeber
On 09/23/2016 05:13 PM, Paul Davis wrote:
> The last time I was working with such a person was deeply illustrative: a
> small technology company doing audio on raspberry pi and beagle boards.
> Using JACK. Having an insanely hard time even getting it work. Even with me
> sitting in with them. Their experience is common. Maybe even the norm. We
> never targetted JACK for such uses (focusing on desktop scenarios).
> Developers think it is cool, was developed on the same OS as they are
> running their new embedded platforms - awesome! Except ... not so much.
>
Exactly what I have experienced. It is all well for prototypes and for
testing out stuff,
but when things become serious, it all falls apart and people may notice,
that jack is not even a good fit for their usecase which may be better fit
by a small custom application.

Also people have a hard time understanding even the "basic" concepts,
for various reasons.

I have seen someone trying to build a simple processing chain for
streaming audio
and setting up a proprietary application as a JACK client.
That was interesting to watch. It took quite some time for him to learn
how to even build, install and use JACK
in a meaningful way, even with me providing some help. In the end it
worked out for testing
and evaluation purposes but I'd never seriously consider that ready for
production usage.

This may sound harsh, but this stuff is simply not a nice choice for
mainstream production use
and so are many things in the LAU universe.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Multiple JACK servers connected in one host?

2016-03-13 Thread Markus Seeber
On 03/12/2016 01:30 AM, Robin Gareus wrote:
> 
> If you want to dig deeper, compile jack2 with --profile it can print
> nice diagrams like
> http://www.grame.fr/ressources/publications/Timing.pdf  including
> wake-up times for each of the clients; then again this is fairly
> advanced and the issue in your case is likely simpler.
> 

Obtaining timig information the clients would have been the next step to
identify then critical path. I think something can be learned from this
data.

___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Multiple JACK servers connected in one host?

2016-03-08 Thread Markus Seeber
On 03/07/2016 08:37 PM, Jonathan E. Brickman wrote:
[...]
> 
> What is happening right now, is I have seven synth+filter chains, all
> run through the single JACK server, all feeding eventually into the one
> sound card.  I have more than ample CPU to run them all, but as you and
> others have explained, one JACK server is reaching its limits to handle
> them all because of the limits of the synchronous nature of everything. 
> So what I intend to do, is to run all of the chains independently,
> asynchronously, on their own JACK servers, and then combine them all
> into a separate final which will connect to the sound card.  This is
> being done already with as many motherboards as desired, but I would
> like to do it within one very powerful box.
> 

Since you did not give much case specific information about the topology
of your processing chain, it is hard to tell where the problem is in
your case and how to solve it. Not sure what's up about all this
asynchronous talk, maybe we talk past each other? (pun intended)
Maybe some visualisation of your jack graph could help, I think patchage
can export the structure of that into a dot/graphviz file, you could
attach that. Information about the strain each of these filters puts on
the CPU would be helpful as a hint too. That would not be the number at
the top of htop, but next to the process of each of these filters.

Except from that, Paul and Fons already made the point about how this is
supposed to work.

Best regards
  Markus
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Multiple JACK servers connected in one host?

2016-03-07 Thread Markus Seeber
On 03/07/2016 02:12 AM, Jonathan E. Brickman wrote:
> Greetings, everyone.  Since I am using 85% of JACK DSP in my primary
> production box, while using 14% of the CPU and 1/8 of the RAM according
> to htop, it appears that I need to develop a way to move forward :-)

14% of what? One physical core? One virtual core? All cores? Chicken?

> I would like to use the power of my box to do the same internally.

Jack should be doing this already in a single instance.

> 
> I have taken a number of hours over the last few days in testing. Thus
> far, my impression is that netjack1, netjack2, and jacktrip are
> explicitly not set up for this.  Using jack2, netjack1 and jacktrip
> worked fine for one client/slave, but a second one froze both, and
> netjack2 did not work at all, I found a web reference stating that
> multijack explicitly does not do localhost unless explicitly set to do
> so at the TCP/IP stack programming level.  Using jack1, netjack1 did not
> connect at all, so I decided to halt for now and ask Those Who Know :-)
> 
> So far, the only clearly workable option, has been to try the Docker
> lightweight virtualizer, and run each JACK server and related
> application chain in its own container.  Anyone have better ideas?

Yes, maybe take a step back and try to find the problem before finding a
solution.

>From what I just read:

* You noticed, that there is a high DSP load for JACK
* You noticed, that there is a low CPU load on you box, which has most
likely multiple physical cores?

So I assume you think the following:
Ok, my Hardware still has free CPU resources, and since JACK is supposed
to be a smart thing, it should be able to utilize all of my CPU cores.
One could think, that JACK just needs to put your clients on different
CPUs so they can run in _parallel_, using up more CPU Cycles and increasing.

Sadly it is not that easy, since this assumes, that your processing
chain actually _can_ be parallelized. Can it? Depends...

If your processing chain looks like a daisy chain, you are out of luck:

mic -> client1 -> client2 -> client3 -> speaker

(fig 1)

Since each client must wait for the previous one, only one client can do
its work at a time, which means only one of your cores can be utilized
_at a time_, the others will just sit there idling around.


On the other hand, if your processing chain looks like this:

mic --> client1 ---> speaker
\-> client2 -^ ^ ^
\-> client3 --/ /
\-> client4 ---/

(fig2)

the clients 1,2,3,4 can run at the same time. JACK _can_ schedule them
to run on 4 different CPUs, which means you can reach a higher average
CPU load while keeping the DPS load lower.

There are many more details, but the most important thing is the question:
"Can my processing chain be parallel?"
"Can I do anything to my processing chain to make it (more) parallel?"

I stop here trying to interpret what you were trying to achieve and
maybe the best thing you could do to get some tips is to describe your
processing chain, maybe something can be worked out. A picture in form
of a graph, says more than a thousand words in this case.

Best Regards
Markus
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] RME madi latency

2016-02-03 Thread Markus Seeber

On 02/03/2016 03:40 PM, Jörn Nettingsmeier wrote:
> On 02/03/2016 02:54 PM, Fokke de Jong wrote:
>> Hi Adrian,
>>
>> I could’ve guessed you were on this list as well :-)
>> I’m going to try this tomorrow when back in the studio, or maybe I can
>> even do it remote if I have left everything patched up correctly :-)
>>
>> I will come back with the results.
>> Thanks for your input!
>>
>> fokke
> 
> watching this with interest, keep us posted about your results and
> longer-term experience with this card!
> 
> 
> best,
> 
> 
> jörn
> 

I have tested the card for a short period of time and can confirm that
it works as intended. The only thing is, that the mixer controls are not
available via alsamixer and the internal routing matrix is fixed. On the
other hand, I guess that is a bonus as something you can not set, can't
be set wrong ;)

The buffersize can confuse applications which assume, that the
buffersize is variable and is always (buffersize = framesize * periods)
but I guess that this is not an assumption that should be made in the
first place.

Measurement with jack_delay seemed plausible too back then.

Was the driver already included in mainline? I saw the patch on
alsa-devel but kind of lost track of it.
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] User eXperience in Linux Audio (rambling)

2015-04-19 Thread Markus Seeber
On 04/19/2015 01:35 PM, Gordonjcp wrote:
 On Sat, Apr 18, 2015 at 11:40:10PM +0100, Harry van Haaren wrote:
 Hi All,

 As promised just at the closing ceremony of LAC, an email opening the
 discussion of User Experience on Linux Audio. To all Developers,
 please use this as a checklist and consider supporting each item. It
 will improve the user experience.

 1: Splash Screen
 If an app takes more than one quarter of a second to open, use a
 splash screen to give feedback. Feel free to contact me directly to
 collaborate on a splash screen graphic if necessary. Ensure the splash
 is shown immediately, before lengthy operations such as scanning for
 
 Just as long as it's not modal, or better yet make it optional.  There's 
 nothing worse than a big ugly graphic blotting out the middle of your screen 
 preventing you from doing anything while you wait for some buggy slow piece 
 of crap to load.
 
 Splash screens are a symptom, not a solution.
 

I think both have a point here. Users, especially Windows users are
often quite strange creatures. They come from an environment where
Software is notoriously slow, bloated and faulty, so for example they
come with a few subconscious expectations and assumptions:

1. I do not trust this thing in front of me, sometimes it works, most of
the time it doesn't. I hate it, I don't want to use it and it is a PITA.

2. If I command my computer to do something, it must be complex and
complicated, otherwise why would I have the computer do it anyway? If it
was easy, I could do it myself!

3. Because computers do complex and difficult stuff, this stuff takes
time and makes noise, (Freezing the gui for a few satisfying moments,
loud rumbling of the hard drive, and and and, Sometimes displaying an
ominous loading- or progress-bar). This kind of feedback is the
resemblance of hard work, exactly the hard work I expect the computer to
do for me (see 2.). While it does the hard work, I anxiously sit in
front of it full of awe and expectations whether the hard work will show
any usable result or just abort with a cryptic message some stupid
programmer most certainly put in just for the purpose of annoying me.

4. If I click on a button and I can't notice any hard work, something
must certainly be wrong because no work was done. So this save button
must obviously be broken, so better press it again and again... oh wait,
it is greyed out and deactivated, better call the developer and tell
him, that the save button does not work...


Nr 4 did actually happen to a fellow developer in the past, so what did
he do? After all his effort to uncouple the UI from the background
processing and optimizing the speed and responsiveness of the
application, he silently shed some tears and put in progress bar that
runs for a fixed time of maybe 1.5 Seconds.Now the user can be sure,
that the program has actually received his command and acted (or at
least acted as if it acted) according to the users command. Because
seriously, saving must at least take one second because it is hard work,
otherwise it is obviously broken ;)

Someone nasty could say, that users want slow and buggy software, but I
am not that cynical, I guess some feedback is enough to give the user a
good feeling.

There are other alternatives than classic splash screens.
1. locking the UI in a visible way
2. displaying a loading bar
3. Be creative, maybe play some hard-drive crackling sound via speakers?

Splash screens have the advantage of empowering the developer to put
marketing relevant stuff there, Donation Buttons, logos, version
numbers... so it's probably not entirely about UX I guess.

Just my 2€

-- Markus
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] Android's 10 Millisecond Problem

2015-04-16 Thread Markus Seeber
On 04/16/2015 07:10 PM, Ralf Mardorf wrote:
[...]
 
 Is it possible to run an Android device by a power supply, when the
 battery is empty?
 
 Regards,
 Ralf
 ___
 Linux-audio-dev mailing list
 Linux-audio-dev@lists.linuxaudio.org
 http://lists.linuxaudio.org/listinfo/linux-audio-dev
 
There is no such thing as the one representative android device since
android runs on many different devices, made by different manufacturers.
Comparing Android to Apple is a bit of a problem here.

Basically, it depends on the device and the workload. For example I can
do a lot of stuff with a Galaxy S3 Phone and the power reserves of the
(stock) power supply are adequate for usual tasks, even for installing
updates, and demanding tasks. For a tablet, this may be entirely
different, since the screen is much bigger.

Cheers, -Markus
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] [p...@linuxaudiosystems.com: [Jack-Devel] jackaudio.org website shut down due to hacking]

2014-06-30 Thread Markus Seeber
On 06/27/2014 11:54 AM, Michał Koziarski wrote:
 Hi,
 
 I could take this on in case there's still need for a volunteer. I'm a
 professional web developer. I'm also in favour of gh-pages, that I use
 quite a bit, as long as it's fine for it to be a static site. It's
 simple, fast, free, made for open source project sites and it's git so
 it works great when different people make changes to the site.
 
 Of course I can't really spend more than about an hour per day on it,
 what with my day job and all, but hopefully it's not a massive job and I
 think I should be able to get it done in a finite amount of time.
 
 Does this sound reasonable? If so, what would be the next steps?
 
 Michał
 

Even tough the site is in fact on-line again, I feel the need for a
little bit of restructuring.
There are some pages, for example the front page and the download page,
that could benefit from a better Design, so I'd like to hear your
opinion about that from a web developers perspective.

Greetings
Markus
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] [p...@linuxaudiosystems.com: [Jack-Devel] jackaudio.org website shut down due to hacking]

2014-06-01 Thread Markus Seeber
On 05/30/2014 10:00 PM, Adrian Knoth wrote:
 Hi!
 
 I'm sure there must be users out there who are familiar with web stuff
 and are burning to help their favourite inter-application audio
 framework. ;)
 
 Step up, please.
 
 
 PS: There is also a semi-complete move to GH-pages. If your're familiar
 with github, you could be the ideal volunteer. ;)
 
 Cheers
 

Hi,
GitHub-pages means, some kind of static site generator may be used?
Sounds good to me, even tough I'm not a web developer, getting some
experience something doesn't sound that bad.

I'd like to evaluate what i can do, would you make a list of contents
and requirements for a new page?

I got this from the other list:
 * the FAQ
* applications list
* API documentation
* stuff that was on trac.jackaudio.org (which is a wiki)

Is the Trac currently used as a Project-management tool and will it stay
as such, or is it just used as a wiki? Maybe it's time to go through the
Information on the site and throw out some old stuff during the process.

TL;DR
I'd like to take this on, but it will take some time, as i have to get
into these things and certainly won't be using Drupal ;)

-Markus
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev


Re: [LAD] AES67 + JACK

2014-05-16 Thread Markus Seeber
On 05/16/2014 05:37 PM, Jamie Jessup wrote:
 I would love to see this happen in the world of LA. I was recently about
 to embark in a HW project for an AES50 implementation, however after a
 quick skim of the standard this sounds a little more exciting :).
 
 A Dante Virtual Soundcard style thing for ALSA/JACK would be amazing.

There is a proprietary ALSA driver for (at least) some Dante Cards, but
you have to ask your reseller specifically for it and pay an additional fee.

-M
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev