Re: [LAD] aBLETON lINK
> On Fri, Sep 23, 2016 at 12:50 AM, Patrick Shirkey < > pshir...@boosthardware.com> wrote: > >> >> > On 09/22/2016 07:30 PM, Tito Latini wrote: >> >> On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis wrote: >> >> [...] >> >>> > Ableton have now done that, albeit by circumventing the hardest >> parts >> >>> of >> >>> > the problem (a tempo map with varying meter and tempo). >> >> What? >> >> >> >> I repeat: that's not an innovation. >> > >> > Did anyone say it was? Why does it matter if it's innovation? >> > >> > Compared to all the prior-art, I suppose the interesting part of Link >> is >> > momentum behind it, along with the apple-style dictated protocol: take >> > it as-is or leave it. Not the usual years of consortium design >> > discussions which may or may not eventually result in consensus and >> more >> > like a floss-like benevolent dictator style (think jack, or LV2). >> > >> > The closest thing to innovation is "Pro Audio company that usually >> does >> > closed-source proprietary software publishes an API and reference >> > implementation under GPLv2" and it work on GNU/Linux, too. >> > >> > That's pretty cool IMHO and I wish more companies would do that! >> > >> > Also coming up with a protocol is the easier part. Documenting it, >> > pushing it out to users, gaining traction in the industry etc is the >> > hard part. >> > >> >> Only for Professional Audio. There are plenty of examples of Open Source >> projects leading the field in other markets. >> > > There are no fields I know of where open source leads in terms of end-user > visible software applications. > > And in terms of non-end-user visible software applications, Linux has > permeated just as deeply into pro audio as anywhere else (perhaps even > more > so). > > > >> >> There are now numerous examples of real companies with real incomes >> contributing directly to open source API's/frameworks/projects without >> having to retain explicit ownership/control and branding rights. >> > > No matter what Ableton or anyone may or may not write, you cannot release > something under GPLv2 and retain "explicit ownership/control", and > branding > rights are of limited value in this domain. > > > >> >> Why is it that after so many years, effort and examples such as the >> Linux >> Audio Consortium, the Linux Audio Conference, ALSA, JACK, LV2, Ardour we >> still encounter this attitude from the proprietary players? >> > > Because we've done a fucking piss-poor job of licensing, packaging and > promoting technology in ways that make sense to the overwhelming majority > of developers and users. > If this is correct the trick appears to be having strong brand awareness and releasing the API on github? > Do you have any idea how many companies I've interacted who are 100% aware > of JACK (and maybe even a little in awe of some of what it can do) and may > even have developed versions of their software that use it, but that > cannot > figure out how they could ever deploy them? > I don't know how many but if they have gone to the trouble of creating the port then all they have to do is package and release it. They don't even really need to invest in marketing it because we do that for them. The issue is not how to deploy but when to deploy. The generous POV is that everyone except Harrison is still waiting for the market to "mature". The cynical POV is that something is actively stopping them from taking the plunge. According to some reports it's a good way to make some extra cash money without having to actually release anything publicly. Just mentioning that you have a Linux port is enough to get the funds flowing for "alternate" development priorities. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
> On Fri, Sep 23, 2016 at 6:00 AM, Patrick Shirkey > <pshir...@boosthardware.com >> wrote: > >> >> I suppose that their marketing department has decided that Linux >> Developers/Users don't represent a big enough share of the market to >> justify committing more resources to the platform. >> > > You have no idea what their marketing department has decided. Admit it. > One can draw reasonable conclusions based on the evidence at hand. > >> >> However JACK also runs on the other two main platforms so what is their >> rational behind completely ignoring it altogether while committing >> resources to creating a competing API? >> > > How many times is it necessary for someone to explain that JACK and AL are > NOT competing APIs ? > Sorry, if I can't just trust you on that statement. Only time will tell but from my perspective they are currently in an aggressive position against JACK. > >> >> Keep in mind that they have explicitly stated that Ableton Live will >> NEVER >> run on Linux. It seems a bit hypocritical to me that highly regarded >> people from this community are proposing to add support for the new >> protocol and at the same time questioning why there is (still) >> antagonism >> towards Ableton. >> > > I have no idea what statement you are referring to, but if I was to guess > it might be when Gerhard Behles, one of the company's (and software's) > founders was at LAC in Berlin in 2007. Which means basically before > Android > took over the world and Chromebooks and ... > To paraphrase Peter Pan, "NEVER is an awfully long time..." They haven't made any public announcements to the contrary, corrections or retractions and they certainly haven't released a Linux port of AL so as far as I (and I presume many others) are concerned the statement still stands. The proof is in the pudding really. Quite simply: Do they have an official Linux port? Do they officially support JACK? Now that it is cool to release Open Source products they appear to have jumped on the band wagon but until they actually bite the bullet and release their Linux port of AL and integrate with JACK on all platforms then it shouldn't offend anyone if I am (or anyone else from round here is) suspicious of their intentions. > If so, this is a statement that is getting on for a decade of aging, and > it > is absurd to view this as policy. You have absolutely no idea what Ableton > is and is not doing with Linux, or what its policies (if there are indeed > any) toward Linux are. I suggest you regard that statement as a bit of > off-its-time sensible marketing wisdom from nearly a decade ago, and move > on. > > >> >> Other proprietary companies have no problems releasing their software to >> run on Linux. > > > And many others are NOT. So what would that mean? (that's a rhetorical > question) > If Harrison, Autodesk and others CAN do it then why "CAN'T" Ableton especially now that they are "apparently" embracing Open Source, devoting resources and even have some "good will" from some highly regarded Linux Audio Developers. Seems like a marketing blunder on their part in regards to winning hearts and minds in the overall Linux sector but other people view the situation with more sinister implications. On the flipside if adopting Link into the Linux Audio Stack means Ableton feels more committed to LINUX and makes some tangible movements in this direction then we might have a publicity coup on our hands. However I'm not betting on that outcome due to their record so far. IMO, the time/effort required to support Link across the board could be better spent on fixing the looping issue in JACK. If/When there is some momentum for Link adoption I will update the Linux Audio Stack diagram to maintain transparency but I am not sold on the real value of Link to Linux Audio at this point. Seems like a one sided affair where they get brand promotion without having to actually commit to Linux Audio. Or to quote from Captain Hook this time "Bad form Peter". -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
> On Thu, 2016-09-22 at 19:58 +0200, Robin Gareus wrote: >> That's pretty cool IMHO and I wish more companies would do that! >> >> Also coming up with a protocol is the easier part. Documenting it, >> pushing it out to users, gaining traction in the industry etc is the >> hard part. > > I agree with this. This thread has been a little bit agressive and I > don't really understand why. > > From my point of view, integration with AL will probably have > interesting side effects among all musical applications. Imagine > jam/performance sessions with musicians combining many different DAWs > and loopers running on multiple platforms. > > The whole point of such a protocol as they've developed it is to > increase creativity and to open up possibilities for collaboration and > new musical ideas. Isn't that one of the reasons we like to hangout on > mailing lists like this one? > Some us us disagree that this IS the "whole point" of Link. IMO anyone who doesn't know about JACK and claims to be a professional audio developer has dubious credentials. In addition there are other existing API's as Tito has explained that predate Link. Given the fractured history that Ableton has with Open Source development and Linux support it should not come as a surprise to anyone on this list that there is some disagreement over the validity of their release process / marketing campaign. I suppose that their marketing department has decided that Linux Developers/Users don't represent a big enough share of the market to justify committing more resources to the platform. However JACK also runs on the other two main platforms so what is their rational behind completely ignoring it altogether while committing resources to creating a competing API? Keep in mind that they have explicitly stated that Ableton Live will NEVER run on Linux. It seems a bit hypocritical to me that highly regarded people from this community are proposing to add support for the new protocol and at the same time questioning why there is (still) antagonism towards Ableton. Other proprietary companies have no problems releasing their software to run on Linux. For example Flame (Autodesk) runs perfectly fine on Linux as does Vmware, Oracle, etc... Even the Tesla cars are running Linux for their multimedia systems. Steam has their own Linux Distribution. It's not like it there is no precedence for Ableton to release a binary only Linux port. More so if they genuinely want Linux Audio Developers to support their profit margins and integrate our software/platform with their product(s) at our expense/time/resources. Of course everyone is free to do what they want but don't try to pretend that it's a shock that some of us are not enthused about this new product. That comes across as lack of insight or outright BS. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
> On 09/22/2016 07:30 PM, Tito Latini wrote: >> On Thu, Sep 22, 2016 at 09:16:12AM -0500, Paul Davis wrote: >> [...] >>> > Ableton have now done that, albeit by circumventing the hardest parts >>> of >>> > the problem (a tempo map with varying meter and tempo). >> What? >> >> I repeat: that's not an innovation. > > Did anyone say it was? Why does it matter if it's innovation? > > Compared to all the prior-art, I suppose the interesting part of Link is > momentum behind it, along with the apple-style dictated protocol: take > it as-is or leave it. Not the usual years of consortium design > discussions which may or may not eventually result in consensus and more > like a floss-like benevolent dictator style (think jack, or LV2). > > The closest thing to innovation is "Pro Audio company that usually does > closed-source proprietary software publishes an API and reference > implementation under GPLv2" and it work on GNU/Linux, too. > > That's pretty cool IMHO and I wish more companies would do that! > > Also coming up with a protocol is the easier part. Documenting it, > pushing it out to users, gaining traction in the industry etc is the > hard part. > Only for Professional Audio. There are plenty of examples of Open Source projects leading the field in other markets. IMO that is the main contributor to the perceived animosity to companies like Ableton from *some* open source developers. There are now numerous examples of real companies with real incomes contributing directly to open source API's/frameworks/projects without having to retain explicit ownership/control and branding rights. The big exception seems to be professional audio where almost all the major players (Harrison is a notable exception) want to invent the wheel and go it alone. Why is it that after so many years, effort and examples such as the Linux Audio Consortium, the Linux Audio Conference, ALSA, JACK, LV2, Ardour we still encounter this attitude from the proprietary players? -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
> On 09/21/2016 11:24 AM, Perry Nguyen wrote: >> >> Though after reading your post to LAD a couple times over it seems like >> there is possibly overlooked but important incongruity between BPM and >> "linear/real-time".. and perhaps that limits the ability of word-clock >> time designators like JACK from seamlessly following BPM? If that is the >> case it is still unclear to me what the specific technical details of >> that incongruity are. >> > > (continuing my own babbling...:)) > > read this? > > http://github.com/jackaudio/jackaudio.github.com/wiki/TransportLimitations > (JACK Transport Limitations) > > ok. now from the top of my head. > > a. jack-transport/timebase (JT) is a centralized master/slave model, > including its API approach; corollaries follows: all JT clients start > and stop on demand and at the same time; netjack clients might drift > apart, unless they implement some sort of PLL/DLL device (anyway, this > assumes one of the participants is master); time reference is absolute > frame position, constant sample-rate (frames/second), starting from a > designated master application, linear (tape-like) timeline model (a > song, session or project as a whole length continuous composition or > arrangement). > > b. ableton-link (AL) is a distributed metronome facility and API; any AL > client may or not be playing its thing on any given time, but when they > play, they *should* start and sync (internally on their own premises) > on beat boundaries on their own best-fit strategy model; time reference > is tempo (BPM; beats/minute); tempo changes are broadcasted (well, dang > truth is multicasted), may be initiated by any participant, then each > other participant may react accordingly (or not) on their own chance, > next cycle or phase, whichever fits best their own designed playback > model--this is why, AL is more suited for loop-based contraptions that > straight linear-tape model ones. > > you can map AL to JT (timebase) if you will, but it's one master's job > to do it--make the time calculations according to its own master, static > tempo-map. > > hth. > cheers > -- > rncbc aka. Rui Nuno Capela It seems that the lack of interest in adding similar functionality to JACK has opened up a gap in the "market". Is there any specific reason that JACK *cannot* be used to enable a similar looping mechanism via the transport control or in parallel? -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
> The people who designedand wrote Link are entirely familiar with JACK (if > only because I taught them about it). > We know that. So are the people at Google who used JACK as the basic design reference for their attempt at low latency audio. > I too was a bit disappointed when Link was announced (last Novemeber) > because it seemed redundant given JACK transport. But once they released > the SDK for iOS and later the code for all platforms, it became clear that > the Link team has come up with something quite different, extremely useful > and really rather clever. Even just their clear identification of > different > kinds of musical time sync is a huge contribution for those of us who > think > about such things. > > Ableton is actually full of quite a lot of software developers who are > into > open source. I don't know why there needs to be the level of disdain and > skepticism for the company itself just because, like most other s/w > development companies, they use a proprietary model. Maybe it's because they explicitly stated that AL would *never* run on Linux and then attempted to explain their justification for that decision with a essay and speech at LAC (but that's just a guess). > Their documentation > for their Push2 surface is an exemplary example of how any company (even > an > open source one like Monome) should and could document a hardware device > and how to interact with it. Likewise, their release of the Link SDK as > GPL > code for all platforms is a remarkably strong statement from a company > whose core products are all released under proprietary licenses. > These are steps in the "left" direction but it's not hard to imagine their marketing department getting veto over any actual attempts at integrating with existing Open Source projects like ex. JACK simply because of the branding opportunities of releasing software like Link as their own standard. Jack => Link hmmm, no similarity there. IIUC, even with all your expert advice AL does not support JACK directly. which seems a shame seeing as JACK is a "spec'ed out, cross-platform reference implementation" that has *already* found its way into hardware. > > On Tue, Sep 20, 2016 at 1:03 AM, Patrick Shirkey > <pshir...@boosthardware.com >> wrote: > >> >> > On 09/19/2016 11:56 PM, Patrick Shirkey wrote: >> >> >> >>> why? >> >>> >> >>> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <tito.01b...@gmail.com> >> >>> wrote: >> >>> >> >>>> What is the content of the network packets ? >> >>>> >> >>>> Regardless, I'll ignore software with that technologogy. >> >>> >> >> >> >> The OP seems to be suggesting that whoever has access to the data >> >> captured >> >> by Ableton Link or the potential backdoor that link *might* enable >> would >> >> use it for nefarious purposes. >> > >> > Ableton link is used to synchronize software and devices on a *LAN*. >> > It basically broadcasts BPM and song-position to the *local* network. >> > >> >> Because netjack isn't good enough or cross platform enough or LGPL >> enough >> or adopted enough? >> >> > Link does not allow to synchronize devices on a WAN. >> > >> > The complete source code is free (GPLv2) you can read it, no strings >> > attached. >> > >> >> Be careful, apparently you might get brainwashed ;-) >> >> >> -- >> 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
Re: [LAD] aBLETON lINK
> On 09/20/2016 07:03 AM, Patrick Shirkey wrote: >> >> Because netjack isn't good enough > > correct. > > jack can have a single timebase master and likewise netjack has a single > net-master. > > Ableton-Link is decentralized: Multiple performers can interact with > each other on an equal level (no master/slave semantics). > > It's not groundbreaking tech. Laptop orchestras and the likes have used > similar techniques since a while, but all prior-art that I know is ad-hoc. > > As far as I know this is the only protocol concerning *musical-time* > that's spec'ed out, has a cross-platform reference implementation and > potential to find its way into hardware. > > Feel free to criticize the protocol on a technical level or hunt for > bugs in the implementation ... or simply ignore it silently. > So then the next question would be is there any reason NOT to integrate it directly into JACK? -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
> On 09/19/2016 11:56 PM, Patrick Shirkey wrote: >> >>> why? >>> >>> On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <tito.01b...@gmail.com> >>> wrote: >>> >>>> What is the content of the network packets ? >>>> >>>> Regardless, I'll ignore software with that technologogy. >>> >> >> The OP seems to be suggesting that whoever has access to the data >> captured >> by Ableton Link or the potential backdoor that link *might* enable would >> use it for nefarious purposes. > > Ableton link is used to synchronize software and devices on a *LAN*. > It basically broadcasts BPM and song-position to the *local* network. > Because netjack isn't good enough or cross platform enough or LGPL enough or adopted enough? > Link does not allow to synchronize devices on a WAN. > > The complete source code is free (GPLv2) you can read it, no strings > attached. > Be careful, apparently you might get brainwashed ;-) -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] aBLETON lINK
> why? > > On Sat, Sep 17, 2016 at 5:44 PM, Tito Latini <tito.01b...@gmail.com> > wrote: > >> What is the content of the network packets ? >> >> Regardless, I'll ignore software with that technologogy. > The OP seems to be suggesting that whoever has access to the data captured by Ableton Link or the potential backdoor that link *might* enable would use it for nefarious purposes. If seriously worried about such issues then it's probably not a good idea to use gmail, cellphones, walk around in most populated areas of the world, participate in modern society, etc... I suggest to not enable an external network connection if using software that has this *potential* security threat enabled *and* it is a cause for concern. +/- 0.2 btc -- Patrick Shirkey Boost Hardware Ltd ___ 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?
On Fri, March 11, 2016 11:59 pm, Paul Davis wrote: > On Fri, Mar 11, 2016 at 7:17 AM, Patrick Shirkey > <pshir...@boosthardware.com >> wrote: > >> >> On Fri, March 11, 2016 6:58 pm, Robin Gareus wrote: >> > On 03/11/2016 08:03 AM, Patrick Shirkey wrote: >> >> If this cannot be fixed in JACK directly we should be able to spin up >> >> multiple instances on the same machine and have them play nice with >> each >> >> other. >> > >> > and how would that be different from splitting the current graph in >> JACK >> > and not preform worse? >> >> Currently it seems that we cant do either so which method is preferable? >> >> According to Jonathan's results he is finding a bottle neck with JACK >> DSP >> with a single server. In the absense of a fix for JACK so that it is not >> a >> bottle neck his solution is to run multiple servers on the same machine. >> However it seems that it is not possible to have more than 2 instances >> of >> JACK running on the same machine without using a virtual >> machine/environment. >> >> According to Paul the issue is that we should not rely on JACK to create >> a >> processing graph like Jonathans. >> > > > Not quite what I said, but close enough. > > 20 context switches minimum per process() cycle. This isn't dramatic, but > it is notable. Some of them might not be context switches if the "Mixer" > stuff is actually an example of a multi-client process - I don't know. > > >> >> I don't see much difference between a single server with multiple graphs >> or multiple servers >> > > > That isn't the choice. The choice is threeway: > >- reduce overhead caused by context switching between programs >- reduce DSP load by running more in parallel (this is dependent on the > graph; JACK2 will do > the best possible already, so if Jonathan is already using JACK2, > maximum parallelism > is already in use) Are we absolutely sure this is the case? That Jonathan has not found a "bug" in JACK2 or the DSP load algorithm? >- reduce the amount of work done by each client. According to Jonathan his multiple cores are barely reaching 5% usage. How can JACK_DSP be so high when there is so much room left to play with if JACK2 is handling the parallelism correctly? It seems similar to my car telling me that I am red lighting when I am only going 20km/hr in second. -- Patrick Shirkey Boost Hardware Ltd ___ 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?
On Fri, March 11, 2016 6:58 pm, Robin Gareus wrote: > On 03/11/2016 08:03 AM, Patrick Shirkey wrote: >> If this cannot be fixed in JACK directly we should be able to spin up >> multiple instances on the same machine and have them play nice with each >> other. > > and how would that be different from splitting the current graph in JACK > and not preform worse? Currently it seems that we cant do either so which method is preferable? According to Jonathan's results he is finding a bottle neck with JACK DSP with a single server. In the absense of a fix for JACK so that it is not a bottle neck his solution is to run multiple servers on the same machine. However it seems that it is not possible to have more than 2 instances of JACK running on the same machine without using a virtual machine/environment. According to Paul the issue is that we should not rely on JACK to create a processing graph like Jonathans. I don't see much difference between a single server with multiple graphs or multiple servers However if JACK is getting overloaded with a single server and we can't split the graph up internally then it makes sense to me that we enable more than two instances of JACK on the same machine without forcing people to use docker or some other virtual environment. Is the issue with multiple servers a priority problem or is it just that no one has ever bothered to test more than two instances on the same machine before? -- Patrick Shirkey Boost Hardware Ltd ___ 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?
On Fri, March 11, 2016 2:13 pm, Paul Davis wrote: > so, you've got 6 non-parallelizable stages. the first stage (3 instances > of > yoshimi, plus stringbassacid plus stringsSSO) has 5 clients that can be in > parallel. The second stage (Mixer/*) has 6 clients that can be run in > parallel. The third stage has 3 clients (Mixer/* and 1 yoshimi) that can > be > run in parallel. the 4th stage has 3 clients that be run in parallel. the > 5th stage has 1 client, as does the 6th. > > basically, this is a picture perfect demonstration to me of why the > process-level parallelism that JACK enables is just a bad idea. > Distributing this amount of processing across 19 JACK clients some of > which > are parallelizable and some are not is, to my mind (as JACK's original > author) precisely how the program should never be used. > > maybe someone will find a way for you to do what you want, but I > personally > think that this whole workflow is ill-conceived. i'm sorry that JACK's > capabilities led you to this, because I think you're not well served with > this tool configuration. > If this was a hardware issue where one physical module had becoming a bottleneck the obvious solution is to add additional modules to expand the pipeline. What is the specific problem with having multiple JACK instances running on the same desktop. Why can't a modern parallel CPU with 8 hyperthreads run multiple instances of JACK? It also offers some interesting potential for session management. If a user has a 64 core desktop it would be absurd if we cannot enable s/he to use it to the full potential because one instance of JACK is getting overloaded when the vast majority of processing cores are not even being used. If this cannot be fixed in JACK directly we should be able to spin up multiple instances on the same machine and have them play nice with each other. > > On Thu, Mar 10, 2016 at 9:28 PM, Jonathan E. Brickman > <j...@ponderworthy.com> > 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. >> >> 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. >> >> The DOT is attached. At max load, the only CPU being stressed more than >> 5% is running just one of the Yoshimi processes, one taking high ranges >> in >> patch SRO; this one CPU is kept at a steady 14% when SRO is sounding >> with >> maximum notes. There is no very significant CPU stress, just maxing-out >> of >> JACK DSP. >> >> -- >> Jonathan E. Brickman j...@ponderworthy.com (785)233-9977 >> Hear us at http://ponderworthy.com -- CDs and MP3 now available! >> <http://ponderworthy.com/ad-astra/ad-astra.html> >> Music of compassion; fire, and life!!! >> >> ___ >> Linux-audio-dev mailing list >> Linux-audio-dev@lists.linuxaudio.org >> http://lists.linuxaudio.org/listinfo/linux-audio-dev >> >> > ___ > 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
Re: [LAD] [LAU] GuitarSynth
On Sat, April 18, 2015 9:37 pm, Gerald wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Clam dep is removed. Can you compile it and run it again? Set jack samplerate to 44100 and Periods to 512 (my settings). Gerald Thanks, I can see and hear GuitarSynth now even with the following settings: creating alsa driver ... hw:PCH,0|hw:PCH,0|1024|2|48000|0|0|nomon|swmeter|-|32bit configuring for 48000Hz, period = 1024 frames (21.3 ms), buffer = 2 periods It would be handy to be able to extend the height of the UI. Already got a serious bit's and bleeps session going on without even trying ;-) Looking forward to rinsing this out. Cheers -- Patrick Shirkey Boost Hardware Ltd On 18.04.2015 13:24, Gerald wrote: I'll look into that. I used clam since it had prettier knobs but dropped it again, as it isn't developed anymore (?) Gerald On 18.04.2015 08:56, Patrick Shirkey wrote: On Sat, April 18, 2015 8:30 am, Gerald wrote: Hi guys, I've started/hacked a small project called GuitarSynth. It is meant as a playfield for exploring pitchdetection and synthesis for Guitar, since I'm a guitarist. You can get on Github (git clone https://github.com/geraldmwangi/GuitarSynth.git). Its really basic but its fun to play with. It take an audio signal (your guitar) extracts the fundamental pitch and drives some wavetable synths. Feel free to manipulate it, I'll be happy to grant people write access to the repo. Btw on IRC my Nick is JimsonDrift, the name of my band (see www.jimson-drift.de). Cheers Gerald Looks like an interesting and fun tool. I had to add this library: apt-get install libclam-qtmonitors-dev - I built the code but when I run I get a segfault: $ make /usr/lib/x86_64-linux-gnu/qt5/bin/uic ../mainwindow.ui -o ui_mainwindow.h /usr/lib/x86_64-linux-gnu/qt5/bin/uic ../SynthBase.ui -o ui_SynthBase.h g++ -c -m64 -pipe -O2 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -I../../GuitarSynth -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I. -I. -o main.o ../main.cpp g++ -c -m64 -pipe -O2 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -I../../GuitarSynth -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I. -I. -o mainwindow.o ../mainwindow.cpp In file included from /usr/include/c++/4.9/backward/strstream:51:0, from ../mainwindow.cpp:23: /usr/include/c++/4.9/backward/backward_warning.h:32:2: warning: #warning This file includes at least one deprecated or antiquated header which may be removed without further notice at a future date. Please use a non-deprecated interface with equivalent functionality instead. For a listing of replacement headers and interfaces, consult the file backward_warning.h. To disable this warning use -Wno-deprecated. [-Wcpp] #warning \ ^ g++ -c -m64 -pipe -O2 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -I../../GuitarSynth -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I. -I. -o gausssynth.o ../gausssynth.cpp ../gausssynth.cpp: In member function virtual void GaussSynth::InitSynth(): ../gausssynth.cpp:29:11: warning: unused variable norm [-Wunused-variable] float norm=0; ^ g++ -c -m64 -pipe -O2 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -I../../GuitarSynth -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I. -I. -o gsengine.o ../gsengine.cpp ../gsengine.cpp: In member function void GSEngine::InitNetwork(): ../gsengine.cpp:50:13: warning: jack_client_t* jack_client_new(const char*) is deprecated (declared at /usr/include/jack/jack.h:97) [-Wdeprecated-declarations] mClient=jack_client_new(GuitarSynth); ^ ../gsengine.cpp:50:42: warning: jack_client_t* jack_client_new(const char*) is deprecated (declared at /usr/include/jack/jack.h:97) [-Wdeprecated-declarations] mClient=jack_client_new(GuitarSynth); ^ ../gsengine.cpp:66:82: warning
Re: [LAD] [LAU] GuitarSynth
-DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -I/home/patrick/code/GuitarSynth -I/usr/include/x86_64-linux-gnu/qt5 -I/usr/include/x86_64-linux-gnu/qt5/QtWidgets -I/usr/include/x86_64-linux-gnu/qt5/QtGui -I/usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I/usr/include/c++/4.9 -I/usr/include/x86_64-linux-gnu/c++/4.9 -I/usr/include/c++/4.9/backward -I/usr/lib/gcc/x86_64-linux-gnu/4.9/include -I/usr/local/include -I/usr/lib/gcc/x86_64-linux-gnu/4.9/include-fixed -I/usr/include/x86_64-linux-gnu -I/usr/include ../synthcontrol.h -o moc_synthcontrol.cpp g++ -c -m64 -pipe -O2 -Wall -W -D_REENTRANT -fPIE -DQT_NO_DEBUG -DQT_WIDGETS_LIB -DQT_GUI_LIB -DQT_CORE_LIB -I/usr/lib/x86_64-linux-gnu/qt5/mkspecs/linux-g++-64 -I../../GuitarSynth -isystem /usr/include/x86_64-linux-gnu/qt5 -isystem /usr/include/x86_64-linux-gnu/qt5/QtWidgets -isystem /usr/include/x86_64-linux-gnu/qt5/QtGui -isystem /usr/include/x86_64-linux-gnu/qt5/QtCore -I. -I. -I. -o moc_synthcontrol.o moc_synthcontrol.cpp g++ -m64 -Wl,-O1 -o GuitarSynth2 main.o mainwindow.o gausssynth.o gsengine.o sinussynth.o squaresynth.o synthbase.o synthcontrol.o moc_mainwindow.o moc_gsengine.o moc_synthbase.o moc_synthcontrol.o -L/usr/X11R6/lib64 -lclam_qtmonitors -lclam_processing -lclam_audioio -lclam_core -ljack -laubio -lQt5Widgets -lQt5Gui -lQt5Core -lGL -lpthread $ ./GuitarSynth2 Segmentation fault $ jackd --version jackd version 0.124.1 tmpdir /dev/shm protocol 25 -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] audio watermark for av sync
Hi, I found this old thread about watermarking. http://linux-audio.4202.n7.nabble.com/Looking-for-Audio-Watermarking-Advice-amp-Tools-td37183.html I have a potential use for watermarking that is entirely above board and completely within the realms of open source technology while also being business friendly at the same time. It's a potential solution to an AV sync issue where there are no other hardware sync solutions available (BLE, NFC, wifi, etc...) The host environment has ONLY audio and video hardware installed. In this situation it has been suggested that watermarking could allow syncing an audio track located on a mobile device with the main audio stream that is playing on speakers in the display room. Obviously the success of this solution is entirely dependant on the response of the mic-signal processing-output chain. I don't think Android devices will be viable in this situation ;-) However I thought it might be interesting for some people here as a counterpoint to the more sinister use of audio watermarking. The processing algorithm could be 100% open source. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Experience driven design and Linux Audio
On Fri, October 3, 2014 7:22 am, Len Ovens wrote: snip SHould Linux target those who only see a comodity? WHo are only looking to have what their idol uses? Or who want the cheapest one that works? The stuff already out there will be what gets bought. Developing HW with Linux is like developing with any other OS, it requires innovation and lots of support. The linux HW has to have what nothing else does and the something has to be seen as needed. Lets see how the mod duo does. I have asked people who already have similar gear about the mod boxes and while they are interested in the platform they are put off by the price. Until they reach the economies of scale to be price competitive there will be a small market. Especially if trying to sell to the existing Linux peeps who are generally pretty cheap when it comes to actually parting with their own personal cash. Several people have tried to tap the market with expensive hardware and had pretty dismal results. However if we look at the success of the low end DIY market ex arduino, rasp pi, rockchip, allwinner that is a pretty good success story. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Experience driven design and Linux Audio
On Thu, October 2, 2014 7:00 pm, Will Godfrey wrote: On Wed, 1 Oct 2014 21:40:10 -0700 (PDT) Len Ovens l...@ovenwerks.net wrote: On Wed, 1 Oct 2014, Paul Davis wrote: Here's an interesting counterpoint or follow up point or whatever. I've queued it to start at the right time, listen till about 31:00 (or longer if you want). The key point I wanted to highlight was Gerhard's point about saying No to user requests. But, being Gerhard, he has other interesting points to make as well. src=//www.dailymotion.com/embed/video/x26axz5?start=1530 allowfullscreen/iframebr An interesting chat. In his case the reasons for saying no to user requests might be different, though not by much. I also realize maybe I am taking the original question off of what it was asking. The original talk was about something that is perhaps not understandable in the context of creation rather consuming. Many of the newer DEs are frustrating for developers (not just SW development), but developers even though there are many, are a very small percentage of computer users. Most are consumers, games and browsing are almost all that happens. From that POV win8, unity, gnome3, OSx, Android, etc. all make sense. From a developers POV (POV meaning personal use), they don't. Someone who is creating music, video or graphics is a developer and their needs are not the same as the consumer. Once that difference is pushed out of the way and one looks at the user experience from a developer's POV the experience that is expected is different but it is still there. snip I found myself nodding all the way through this! Also, it seems that as time goes by a lot of people are using steadily more powerful equipment to actually do less! Whether this is what they want to do or whether it's what the interface *allows* them to do is a moot point. As someone who tries to get the most out of anything I use, I find most commercial software extremely frustrating in the way it strait-jackets users. I think this also blocks curiosity and maybe stops more youngsters joining the creative communities. I think this relates back to the topic as in who's experience should lead the design? If youngsters are people under the age of, say 25 then, most of them will be blocked from LAD by not having access to a Linux PC. The ones who do will mostly be doing academic study, scientific research or working for governments who have chosen Linux instead of the other options. It's increasingly unlikely they will have Linux Desktop PC's at home. Very few new people are taking the time to install Linux OS's on desktop PC's and the desktop market is in decline for the consumer portion across the board. The majority of the shift to Unix has been for Android, ChromeOS, OSX with firefoxOS and Tizen coming closer to fruition each day. The remaining professional portion of the market which I assume Harry is targeting for a sustainable income is well and truly in the OSX camp. It's going to be hard to pull them away from OSX to this OS. Even with really slick interfaces they generally have a different mindset that defines their reasoning. As I was told once. it's not about how much money they can save, but how much money they can make... Linux has seen wide adoption in the embedded audio hardware market but many of the companies that make audio hardware running on Linux systems do not participate directly here. So in terms of usability and this discussion the majority of LAD professionally focused developers are targeting the scientific/academic markets and embedded hardware markets. In that case usability takes second place to raw power and functionality. There is also the web market but I am in a clear minority on the importance of that round here. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Experience driven design and Linux Audio
On Thu, October 2, 2014 7:44 pm, Neil C Smith wrote: On 2 October 2014 10:28, Patrick Shirkey pshir...@boosthardware.com wrote: the desktop market is in decline for the consumer portion across the board. Assuming by desktop you mean traditional PC market, various news stories I've read over the last few months would suggest that's not declining for the first time in years, and potentially even seeing some growth. I've seen those reports too. They are optimistic but potential growth is not the same thing as actually growing. It's more likely to be corporate buyers replacing existing stock. The current situation is the consumer desktop PC market when it comes to audio/multimedia has been decimated by mobile. The Linux Audio Market is currently doing best in embedded hardware. If we want to consider Android as a Linux OS then Linux Audio is doing the best that it has been for years with many companies that have nothing to do with LAD making a business out of their Android applications. The corporate market is still there as a potential battle ground and will probably never go away but getting Linux Audio into the corporate market is a very tough slog. Even at companies where they have massive investments in Linux infrastructure and embedded hardware they are still using OSX for multimedia production and M$ for general purpose administration. It's almost impossible to convince an established Digital Media department that Linux is an appropriate platform for their team members. Firstly there is a massive lack of expertise and training. For example, It is very rare to see a job ad for a multimedia position that uses open source technology. The Blender community is making some headway in the training aspect of the problem but it is slow going. Nearly every professional multimedia person working in corporate space uses those other tools and platforms without question. To change that will require getting into the heads of corporate managers so they make decisions based on a different set of goals. It's a tough sell. It will also require students to choose Open Source over proprietary and that is also a hard nut to crack because the proprietary companies offer incentives to the HoD's that open source can't match. Will Linux Desktop professional or consumer multimedia ever become a growth market? I am not convinced that putting additional effort into usability is the key to cracking it. IMO there are other issues that need to be resolved first. Getting a couple more big names in on the game will be useful too. I recall Native-Instruments were on the fence a couple of years back. They needed more convincing at the time. Maybe they have an update about their assessment of the current market? Has anyone here actually tried selling *any* kind of app on the Ubuntu App Store? Does anyone have actual data about the amount of people out there who use LAD tools? From my perspective the ad hits on LAU Guide are pretty much static after the past 4 years I am not seeing significant growth or decline month on month. One could spin it that we have seen overall growth because it is unlikely that a lot of the same people would return to the LAU-Guide on a regular basis. That suggests that there is a reasonable sized potentially untapped market out there of at least 100k. Who are these mysterious people and will they spend any money? If I had tracking tags on the site I might be able to provide more details but I don't. Until someone nails a mega successful app/model with Linux the other companies waiting in the wings will continue to dip their toes. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Experience driven design and Linux Audio
On Thu, October 2, 2014 9:14 pm, Neil C Smith wrote: On 2 October 2014 11:48, Patrick Shirkey pshir...@boosthardware.com wrote: I've seen those reports too. They are optimistic but potential growth is not the same thing as actually growing. It's more likely to be corporate buyers replacing existing stock. eg. http://www.warc.com/LatestNews/News/PC_sales_rebound_in_Western_Europe.news?ID=32866 Would suggest you're correct in being *mostly* about corporate buyers, but not entirely - still +2% in consumer sales, which isn't declining! Is that potential growth or actual though? Still, 88.2% of statistics are made up on the spot :-) Will Linux Desktop professional or consumer multimedia ever become a growth market? I'm intrigued to see what effect developments in the gaming arena may have on consumer Linux usage over the next couple of years, or on general commercial attitudes in other sectors. If SteamOS becomes a fully fledged distribution on the scale of Ubuntu/Fedora then it might have an affect on adoption rates for LAD software with the young crowd. NVidia is putting a lot of effort into expanding the use of GPU's with CUDA/OpenCL API's so that might also have a positive affect on adoption but only if we build the tools to take advantage of the hardware. FFMPEG developers are doing a great job of keeping things progressing on that front. But LAD'ers could do more to build out tools that leverage GPU's. We could get some more wind in our sails if some well known companies/artists/producers actively promoted their support for Linux OS and encouraged adoption. That has to be a two way street though. For example famous artists usually give endorsements for something in return. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Experience driven design and Linux Audio
. If no - then this is a different position altogether. And this then has nothing to do with learning or dumb users. Louigi. On Wed, Oct 1, 2014 at 5:20 PM, Paul Davis p...@linuxaudiosystems.com wrote: On Wed, Oct 1, 2014 at 9:01 AM, Florian Paul Schmidt mista.ta...@gmx.net wrote: The important point was though that left to their own devices the non-enthusiasts will be slaughtered by the software they use and maybe we have a responsibility to protect them from themselves. slaughter is perhaps a strong term. perhaps a more nuanced description might run something like this (taking a little inspiration from the video): creating and maintaining **consumer** software with a very good user experience is expensive (relative to other tasks that people do) and takes a significant amount of time. therefore the creation and maintainance of this sort of software requires resources that are not clearly available to most open source efforts. the proprietary software that manages to do this is influenced at some level by where its creators and maintainers get their income from, and the development of the free model used in particular by google points in a direction where the software must allow/empower/enable behaviour by the software developers that are not in the users' best interest (e.g. selling data about the users). ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- Louigi Verona http://www.louigiverona.ru/ ___ 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
[LAD] Embedded audio SoC supplier: audio player
Hi, I'm looking for a supplier who can provide a turnkey or white label LOW COST linux compatible portable audio player. SoC embedded linux device. 10k - 150k units. Some hardware customisations may be required. Any company that is interested in quoting on this project please contact me directly to discuss the details. -- Patrick Shirkey Boost Hardware Ltd ___ 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
Re: [LAD] Open Source to be or not to be?
On Tue, July 1, 2014 3:09 pm, Stéphane Letz wrote: Le 1 juil. 2014 à 05:56, hermann meyer brumm...@web.de a écrit : Am 01.07.2014 00:27, schrieb David Robillard: On Mon, 2014-06-30 at 21:58 +, Fons Adriaensen wrote: On Mon, Jun 30, 2014 at 11:13:06PM +0200, Stéphane Letz wrote: 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 ) : And what's the point of running a concert hall reverb in a web browser ? Providing a new 'business model' for audio engineering ? With some advertising around it and Google reaping the benifits and diverting them to some low tax island inhabitated by the stinking rich and their imported household slaves ? If that is the future of open source software, I'll step out. Or is it some form of masturbation for IT engineers who have nothing better to do ? Or are they too stupid to grok what's going on ? ++ UIs are one thing (not without their own problems, but running remotely on pretty much anything is at least useful), but all this DSP in the browser (or Javascript, period) nonsense is just that. It's literally the least appropriate thing to be doing on that platform I can think of. One of the fun things you can do with compilers (like Faust) is output pretty much anything as your machine code. What's fun, however, is not always sane... Native code aversion is a serious problem in the entire computing world, which continues to snowball because all the language/etc innovation gets directed at VMs for no particularly good reason (and/or you get half-baked amateurish garbage like Javascript/PHP from people who have no business inventing programming languages in the first place). I don't need a bloody virtual machine, I've got a real one, thanks. Javscript doesn't even have real numeric types or sane lexical scoping. The entire computing world is supposed to move to this joke, even for high performance and real-time tasks? Give me a break. /rant One way I could imagine to use this: If you put this html site as example on your project site, so users could just test it, without download or install. If they like it, they could download it for real work. Or just drop the code link that is available in the upper part of he HTML page in the export tool of FaustLive. In a matter of minutes you can generate the *native* optimized tool you may want as a plug-in or standalone application. This is a new way to promote DSP code reuse we think interesting. Or enabling people who do not have the expertise to run a native app to do something that they would otherwise not be able to do. Let them view some advertising and even (god forbid) pay for the service. Not everyone has the privilege of lifetime tenure at a government funded cultural institution or wealthy benefactors with pockets full of cash so they can afford to spend their lives working for free on open source technology. If some random marketer wants to spend their clients money on google ads and happens to have their ad appear on my website I'll take the 30c. It helps cover the cost of paying for the server and domain. Let's call it diversification. Anyone who is serious will quickly understand that a native app is a more powerful solution and will look for those alternatives. If they are also provided with information about the alternatives the web version becomes a marketing tool for native apps. Most of the ad spend profit comes from the ideation, design and development process. The actual cost of the campaign is usually a smaller amount. That gives developers, designers and project managers an income which many of them use to self fund their own personal work with a large number of the developers contributing to open source projects. If we take out the marketing industry then we have to find a replacement for those jobs. With the current state of the world it will be a while before the marketing industry is replaced by an international space exploration social co-operative. It could be argued that the marketing industry has enabled a lot of people to stay employed during the past 6 years of global financial meltdown without having to resort to participating in the military industrial complex. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Streaming AV/midi
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
Re: [LAD] Open Source to be or not to be?
On Tue, July 1, 2014 8:52 pm, Stéphane Letz wrote: Le 1 juil. 2014 à 12:37, Fons Adriaensen f...@linuxaudio.org a écrit : On Mon, Jun 30, 2014 at 06:27:05PM -0400, David Robillard wrote: Native code aversion is a serious problem in the entire computing world, which continues to snowball because all the language/etc innovation gets directed at VMs for no particularly good reason (and/or you get half-baked amateurish garbage like Javascript/PHP from people who have no business inventing programming languages in the first place). I don't need a bloody virtual machine, I've got a real one, thanks. Couldnt agree more. It's all just creating extra layers on the onion, in the illusory expectation that those will be more 'standard' than the ones below. Commercial forces will make sure that such interfaces will diverge anyway. And more often than not they just exist to ensure some intermediate parasites can profit from them. It sometimes makes me think of they way tomatos are being distributed and sold here in Italy. They will travel up and down the entire country (either physically or just virtually) a number of times before ending up in the shops. Both the producers and the consumers are ripped off by middlemen taking their profit on redundant steps. Ciao, -- FA This is exactly one aspect Faust is trying to address from day one : having one high level DSP specification that the compiler can easily deploy on a wide variety of platforms: from OWL pedal, (http://hoxtonowl.com/2014/04/owl-and-faust/), regular OS, up to easily deployable Web versions, that can possibly directly be used, or a least give access to the original code for easy re-deployement. Why refuse that? Apparently Fons believes that everything he does is sPeSHaL and should be exempt from the encroachment of market forces. Apparently everyone else who uses open source code for non altruistic purposes is also a parasite. Apparently if you have a nice cushy job working for a government funded non profit organisation you are a higher being and not subject to the general forces that the rest of the world has to contend with. I believe this is called entitlement. Apparently Fons also exists off air and delicately collected rock filtered natural spring rain water and has no need for the other trappings of modern life that general market forces provide. Fons is truly a saintly enigma destined for greater things that are not of this mortal coil. Oh, Hail to the Fons! -- Patrick Shirkey Boost Hardware Ltd ___ 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?
On Tue, July 1, 2014 9:29 pm, Fons Adriaensen wrote: On Tue, Jul 01, 2014 at 09:13:06PM +1000, Patrick Shirkey wrote: Fons is truly a saintly enigma destined for greater things that are not of this mortal coil. Ad hominem remarks are usually a clear sign of not having anything better to say. FYI, Fons will very probably move to Germany in a few weeks, to be employed as Senior Researcher by a *very* big, not government funded and profit making corporation. How this will affect my ability to stay active in open source audio is still a matter to be discussed. But it's very well possible that you will get rid of me, so start preparing the feast. I'll eat my hat if Fons gives up open source development because he has to commit all his personal resources to the Man. -- Patrick Shirkey Boost Hardware Ltd ___ 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?
On Tue, July 1, 2014 10:06 pm, Etienne Rouge wrote: This topic's just gone full chaos quite a while ago. I'd love to read things without seeing people namely attacked or things completly off topic. Open source is a great ideal. But *today* it's a thankless ideal. What about tomorrow ? Either we quit this ideal and just go back 20years in the past (and if we have to chose a closed proprietary market, I'd rather have those good ol' big boxes full of stuffs rather than DRMs - which are both based on the same economical model) or we find a way to get open source developers rewarded. Rewarded socially, personally, and financially. Solving that is the only way to stop escalating to the emotional level at light speed. And that'd be great. Your opening rant was pretty emotional and potentially insulting to the guitarix team and the above is not much less. Welcome to Linux Audio. A bunch of emotional artistes/developers ranting about the state of things with occasional forays into useful information and community cohesiveness. The latter often being considered dirty words uttered by uninitiated well meaning idiots. Parasites and pedants, godly beings with entitlement syndrome and the barely literate wholly unwashed. It's a rare brew. These ideals that you speak of don't mean much without the support of a wider community but not everyone can justify contributing their time/energy with zero financial reward. So while some people consider it to be theft if other people find a way to profit from open source other people consider it to be a useful and worthwhile outcome that in the long run benefits the wider community. Fons wouldn't have to work for the man if he was able to generate a decent income from his open source ouvre. Yet he has routinely been one of the most vocal in his abhorrence of anyone profiting directly from his code. Even more so if someone else has figured out a way to do it that he personally doesn't have the motivation or interest to do on his own. Herman doesn't deserve to be painted as the bad guy, neither Stephane. They are both active and genuinely contributive LAD'ers who are making worthwhile progress and providing useful results. Thanks. T. On 01/07/2014 13:47, Patrick Shirkey wrote: On Tue, July 1, 2014 9:29 pm, Fons Adriaensen wrote: On Tue, Jul 01, 2014 at 09:13:06PM +1000, Patrick Shirkey wrote: Fons is truly a saintly enigma destined for greater things that are not of this mortal coil. Ad hominem remarks are usually a clear sign of not having anything better to say. FYI, Fons will very probably move to Germany in a few weeks, to be employed as Senior Researcher by a *very* big, not government funded and profit making corporation. How this will affect my ability to stay active in open source audio is still a matter to be discussed. But it's very well possible that you will get rid of me, so start preparing the feast. I'll eat my hat if Fons gives up open source development because he has to commit all his personal resources to the Man. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ 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
Re: [LAD] Streaming AV/midi
On Tue, July 1, 2014 10:41 pm, drew Roberts wrote: On Tue, Jul 1, 2014 at 5:34 AM, Patrick Shirkey pshir...@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. 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/ ___ 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
Re: [LAD] Streaming AV/midi
On Wed, July 2, 2014 12:57 am, Arno Däuper wrote: Hello, 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? maybe you can use the fact, that Midi is serial data. It could be possible to pipe it into netcat. Netjack already takes things a few steps further than that with audio and midi streams. Integrating Icecast with netjack would be a powerful tool. I have asked on the icecast list if they have thought about such things. -- Patrick Shirkey Boost Hardware Ltd ___ 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 5:16 am, drew Roberts wrote: On Tue, Jul 1, 2014 at 11:34 AM, Patrick Shirkey pshir...@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 pshir...@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 ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ALSA frustration
On Tue, April 22, 2014 5:44 am, Fons Adriaensen wrote: For the N-th time I've set aside a day to try and read some of the ALSA documentation. For the N-th time I've completely lost my way in a web consisting of * The complete lack of any documentation that explains the concepts, the big picture, and the terminology. * Completely useless docs, of the form: function xxx_set_yyy (parm_zzz) sets the yyy of xxx to zzz. or similar, in other words something generated automagically and completely uninformative and redundant. In particalur if it's impossible to find out what yyy is supposed to be or do in the first place. * Uncomprehensible English. * When trying to learn something from actual source code or examples, layer upon layer of syntactic sugar making it virtually impossible to understand what's going on. Cleaning up this stuff would make a good project for some students to get involved with. I wonder if there are any university professors who could organise such a project? Otherwise we (LAD) could pitch it to SUSE/Ubuntu/redhat/etc... or the Linux Foundation as something that needs some funding support. All this more than ten years after ALSA was announced. I *do* understand those hardware manufactureres who just refuse to try and write an ALSA driver. Alsa-devel is a very heavy traffic list. There are a lot of companies providing support but they seem to be mostly mobile chipset drivers. In this case my very humble endeavour was just to find out if or not it would be possible to create something similar to the alsa_jack plugin that would actually present itself as a sound card, so that (badly written) apps would be prepared to use it. If someone knows the answer to that question and can also explain it I'll commend him/her in my prayers. -- 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) ___ 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
[LAD] streaming multiple tracks with html5
Hi, I can successfully play multiple independant tracks with html5 api. In order to achieve sample accurate glitch free playback I am using the prebuffer method. However, I would like to stream the media. Looking at the various options for streaming I have not run into a perfect solution for streaming multiple tracks with the html5 api. I can see several potential attack vectors. 1: extend icecast to support multiple tracks/stream 2: extend the JACK API to integrate with option 1 3: extend the html5 API - possible but it would need to have more than just me supporting the move. 4: custom solution with new/existing multichannel codec I'm sure that others have already thought about this problem so am I missing something obvious? This could be useful for other services like bandcamp, soundcloud, etc... I think we have an opportunity to guide the direction if we come up with a solid open source solution. *NB. This thread is intended to be a serious developer discussion. Please do not respond to this thread if you do not have specific information to add or discuss on this topic. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] opencl benchmark results
Hi, For those of you who are interested real world results for ffmpeg with opencl we have run some benchmarking tests across our cluster. At the end of last year there was a flurry of activity integrating opencl with ffmpeg. The work was undertaken by multicorewareinc who is also the official keeper of the code for AMD's proprietary version of ffmpeg. We have found that leveraging opencl with the latest development version of ffmpeg gives us upto 4566 DP-MFLOP on a single machine. Adding in the OpenCL component (GPUs) gives us around a 64% speed boost on AMD A4's. We got upto 400% increase on our intel machines (with alot of NVidia CUDA cores). We also noticed that essentially the same AMD/ATI card on a different bus (AGP-8 versus PCI-E) only picked up an extra 6% in speed. So clearly the recent work on the opencl integration with ffmpeg has provided some real world dividends. Just for the record our local cluster is clocking in around 20GFlops with the opencl code in the mix. We haven't added in the cloud servers though so that number is low. While we are not a not a threat to the big players, combining resources within the wider open source community creates a very serious competitor that shouldn't be ignored. Cheers -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK, cgroups and systemd
On Sun, January 12, 2014 11:17 pm, Dominique Michel wrote: Recently, I experimented with Debian sid, which use systemd. Systemd idea is nice, but its implementation is a catastrophe. It is more than one year I am using the kernel cgroups on gentoo to get rt scheduling with JACK, that without any trouble. On Debian, this is just impossible, because whatever I try, systemd insist to put what it think is good to have into the rt cgroup, which soon or later result in a complete system freeze with even dead magic keys. After loosing my time a few days with this, I removed Debian and installed gentoo instead. I found the reason here: http://article.gmane.org/gmane.linux.kernel/1063354 Lennart Poettering: Well, this feature is... completely irrelevant for normal desktop people. ... In fact, I just prepped a patch to systemd to move every service and every user session into its own cgroup in the 'cpu' hierarchy (in addition to the group it already creates in the 'systemd' hierarchy). Another completely idiotic stuff of this guy. The point of the cgroups is it is possible to setup them for whatever use will be made with a computer, and this guy think he have the insane and pretentious capability to decide for every single user of the use they will made with their computers, and he is suggesting users doing something else are abnormal. He must be stopped! That patch is over three years old. It seems like you have found a loophole in the logic that was used to justify it. Granted, it's annoying but it just means we have to find a better solution. Similar to Fon's main objection to jack-session being *not flexible enough*. We all knew it would cause problems for specific use cases but we still haven't found a perfect solution to enable the flexibility that Fons identified while also allowing people to get on with the task at hand. Hence we have the less flexible but still useful for most use cases version of jack session. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [Jack-Devel] JACK, cgroups and systemd
On Mon, January 13, 2014 2:28 am, Dominique Michel wrote: Le Mon, 13 Jan 2014 00:22:40 +1100 (EST), Patrick Shirkey pshir...@boosthardware.com a écrit : On Sun, January 12, 2014 11:17 pm, Dominique Michel wrote: Recently, I experimented with Debian sid, which use systemd. Systemd idea is nice, but its implementation is a catastrophe. It is more than one year I am using the kernel cgroups on gentoo to get rt scheduling with JACK, that without any trouble. On Debian, this is just impossible, because whatever I try, systemd insist to put what it think is good to have into the rt cgroup, which soon or later result in a complete system freeze with even dead magic keys. After loosing my time a few days with this, I removed Debian and installed gentoo instead. I found the reason here: http://article.gmane.org/gmane.linux.kernel/1063354 Lennart Poettering: Well, this feature is... completely irrelevant for normal desktop people. ... In fact, I just prepped a patch to systemd to move every service and every user session into its own cgroup in the 'cpu' hierarchy (in addition to the group it already creates in the 'systemd' hierarchy). Another completely idiotic stuff of this guy. The point of the cgroups is it is possible to setup them for whatever use will be made with a computer, and this guy think he have the insane and pretentious capability to decide for every single user of the use they will made with their computers, and he is suggesting users doing something else are abnormal. He must be stopped! That patch is over three years old. It seems like you have found a loophole in the logic that was used to justify it. Granted, it's annoying but it just means we have to find a better solution. Similar to Fon's main objection to jack-session being *not flexible enough*. We all knew it would cause problems for specific use cases but we still haven't found a perfect solution to enable the flexibility that Fons identified while also allowing people to get on with the task at hand. Hence we have the less flexible but still useful for most use cases version of jack session. With the cgroups, that flexibility exist. One of the main point of the cgroups is to be flexible enough to be setup for any possible use case. But with a systemd system, that flexibility doesn't exist any more, because the only possible normal use case permitted by systemd is to run a GUI (as stated by the normal one in charge of this mess). It is more than 1 year I use the cgroups within an openrc system, and you can do whatever you want with the cgroups. The same apply for sysv init system. What made me mad in that story, is not because it is a bug into systemd which made a kernel function to misbehave, I know very well that the only one that doesn't make bugs is the one that doesn't make code, but this is the complete lack of consideration for other needs than what he consider to be the needs of a normal desktop user. Which strongly suggest users with other needs are abnormal users. Which in turn imply that person is a racist when he suggest I am abnormal. And I am not the only one, systemd will break any cgroup configuration for any other use case than to run a GUI. Well we also see similar issues with PA and JACK. The reasoning appears to be that the different camps are not really interested or motivated to scratch each others itches and no one is being paid to do the dirty work to make sure the corner cases are being polished. I am working on getting some official funding for the latter so this issue interests me from that perspective. It seems the days are over when people had the time or motivation to fix the tricky and annoying integration issues under there own steam. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
On Tue, January 7, 2014 12:11 pm, Paul Davis wrote: Compare and contrast for interesting sociological effect, if you will, to the treatment received by Galileo. Evans wasn't killed for his thoughts but other people are still getting taken out regularly by the establishment. Barnaby Jack, Aaron Swartz, etc... Anyway, the same forces leveraged for acoustic levitation appear to have a wide range of uses. IIUC, that French paper fingers it as a useful method for knocking out tumors and blood clots with an ultrasound machine. I've witnessed it being used for the latter when my wife was pregnant. The crux is that it can create powerful and interesting tools if used appropriately. It can also be used to create WMD's if used inappropriately. Kind of takes the wind out of the whole Iran Nuclear issue if anyone with a powerful enough computer and a handle on Audio engineering can create a neutron bomb with supplies from the corner store or the local medical facility. How does the CIA and the NSA plan to stop the terrorists from building one of those? Will we see them being dropped from plans in Syria next or is Al Quaida going to be funded by the Saudis to stage another false flag attack using French weapons built in Russia so the US has a suitable reason for launching an airstrike on behalf of Israel under cover of the latest UN Security Council Resolution which the Chinese vetoed with Iranian support as observers? But I digress again. Tsk, Tsk., me. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
On Sun, January 5, 2014 7:19 am, Fons Adriaensen wrote: On Sat, Jan 04, 2014 at 06:16:31PM +0100, Dominique Michel wrote: According to that presentation http://www.dalembert.upmc.fr/Oleron2010/docs/Presentations/Oleron-Barriere.pdf it look like Langevin (which is the same than Rayleigh first formula in 1902) apply well when we are long enough from the source, and when we are in its vicinity, Rayleigh (1905) must be applied. Interesting, thanks for the pointer. And it closes the circle... The first slide is a quote from one of Beyer's papers: It might be said that radiation pressure is a phenomenon that the observer thinks he understands â for short intervals, and only every now and thenâ I remember reading the paper that comes from a very long time ago, and that was what inspired my remark about radiation pressure being one of the more elusive topics in acoustics ! IIUC there are some people who understand it very well but the application of their knowledge is considered classified so it's not released into the public domain if it is even written down anywhere. A bit like RSA decryption used to be. The funny thing is that the technology that can be created using this technique would probably solve the energy crisis if this knowledge was allowed to be used for civilian purposes like power stations. It would probably also be useful for deep space exploration. ( Avatar scale not Hubble scale ) Depends on the fuel used of course. One thing we do know is the humble pistol crab can generate impulses with the same heat intensity as the surface of the sun and some salty water. What other exotic mixtures would allow for is anyones guess. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
On Mon, January 6, 2014 2:33 am, R. Mattes wrote: On Mon, 6 Jan 2014 01:28:58 +1100 (EST), Patrick Shirkey wrote IIUC there are some people who understand it very well but the application of their knowledge is considered classified so it's not released into the public domain if it is even written down anywhere. A bit like RSA decryption used to be. ??? Must be good drugs over there ... From the Wikipedia article on RSA: Wikipedia. Instant truth Just add the complement set. The RSA algorithm was publicly described in 1977 by Ron Rivest, Adi Shamir, and Leonard Adleman at MIT; the letters RSA are the initials of their surnames, listed in the same order as on the paper. Or do you want to claim that a way to _break_ RSA (decryption) is known but not published (i.e. there's a non-quantum algorythm to solve prime factorization). People knew how to decrypt RSA before it was released. Just saying. Besides that there is *nothing* to prove the solving factors of primes is an inherently difficult task. Separately these days any company with a few 10's of thousands $$$ available can purchase the hardware to do the job with brute force but there are other more subtle methods. Like the NSA paying companies to use broken algorithms by default, etc... But I digress. The funny thing is that the technology that can be created using this technique would probably solve the energy crisis if this knowledge was allowed to be used for civilian purposes like power stations. It would probably also be useful for deep space exploration. ( Avatar scale not Hubble scale ) gee, really good drugs ... I guess you don't have the information that I have ;-) Lets go, bring out the naysaying, heretical, finger pointing. Just let me get a shot in now before it descends into truly dangerous territory. Yo Mama is so fat they can't launch her into orbit , land her on the moon and then return her to Earth. Depends on the fuel used of course. One thing we do know is the humble pistol crab can generate impulses with the same heat intensity Over here, impulse is measured in mass x velocity, neither of which expresses heat intensity (in kelvin?). Care to elaborate? The heat generated when the *snap* occurs is as hot as the surface of the sun. Watch the video... -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
On Sat, January 4, 2014 11:19 am, Fons Adriaensen wrote: On Fri, Jan 03, 2014 at 05:01:33PM -0600, Charles Z Henry wrote: The peak pressure difference occurs where the volume velocity is zero. The location of the peak spatial derivative of pressure coincides with the location of peak volume velocity. I don't think acoustic levitation can be explained as long as linearity is assumed - because in that case there can't be any constant term in the forces that he acoustic waves generate. So what's going on here is probably a lot more complex than we imagine, and the way it's 'explained' in the video is completely bogus. It seems like this technique could be used to move small objects a fairly large distance as long at the beam forming is applied correctly. I imagine the objects would start to get hot at some point. Does cavitation have a role to play? I wonder what the results would be with other gases or fluids? Is it theoretically possible to lift much larger objects if they were contained in a different gas or fluid rather than standard earth grade air? -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Audio Levitation
On Sun, January 5, 2014 12:39 am, Fons Adriaensen wrote: On Sat, Jan 04, 2014 at 09:24:54PM +1100, Patrick Shirkey wrote: Does cavitation have a role to play? No idea. If it does that could be rather destructive on some materials. This little guy seems to have mastered the art: http://www.youtube.com/watch?v=1jvcgz-BiHs I suppose it is possible that some materials could be quite energy efficient as they are destructed. I wonder if it is theoretically possible to harness this affect to generate energy from some exotic materials thereby using sound as a tool to generate energy which could be used to generate more sound thereby creating a pretty impressive feedback loop. What is clear is that acoustic radiation pressure plays a role. And that's a subject that has caused a lot of confusion and false results throughout the history of acoustics as a science. Some big names (including Rayleigh) have burnt their fingers on it, so it's not and easy matter. To prime the confusion, there are at least two formulations of acoustic radiation pressure: one from Rayleigh (which depends on non-linearity) and one due to Langevin (which does not depend on it). Theoretically would an ambisonic levitation system be able to lift an object with large surface area, high rigidity and low mass? For example a carpet made from layered graphene? Would it require less energy than an equivalent magnetic levitation system? I wonder how much graphene is required to support an object with the mass of a human. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Audio Levitation
Theoretically, how big can this scale? http://www.youtube.com/watch?feature=player_embeddedv=odJxJRAxdFU -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Usb Audio Driver
On Wed, December 11, 2013 7:44 am, Lucas Takejame wrote: Hello LAD, I'm working in company which is developing a guitar pedal board which runs Linux (arch) and my task now is to make the kernel's usb audio driver more appropriate to our sound card. I'm kinda lost in this since i have a brief knowledge on usb protocol so I was hoping that you could give me some directions on how can I optimize the driver latency wise, any tips? The ALSA USB Audio driver is already highly optimised. If you are seeing specific issues the alsa-devel mailing list is a better place to discuss. Or are you looking to optimise the kernel and operating system? FYI, other LADers have been using usb devices with 64 frames per period which provides less than 2ms round trip latency. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] html5 audio filters
On Mon, October 14, 2013 4:39 am, Patrick Shirkey wrote: On Mon, October 14, 2013 4:08 am, Markus Seeber wrote: Hi, i'm not sure, but you could have a look at what he is doing: http://mohayonao.github.io/timbre.js/reverb.html That is quite a large JavaScript framework, but maybe the right place to start? Looks interesting but it doesn't have support for ogg afaict. However I might be able to do something with the examples. Anyone else have any other suggestions? For anyone interested I found this library which is pretty useful : https://github.com/Dinahmoe/tuna http://www.html5rocks.com/en/tutorials/casestudies/jamwithchrome-audio/ Am 10/13/2013 06:58 PM, schrieb Patrick Shirkey: Hi, Can anyone point me to an example for echo/delay/reverb filters using html5 audio? -- 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
[LAD] html5 audio filters
Hi, Can anyone point me to an example for echo/delay/reverb filters using html5 audio? -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] html5 audio filters
On Mon, October 14, 2013 4:08 am, Markus Seeber wrote: Hi, i'm not sure, but you could have a look at what he is doing: http://mohayonao.github.io/timbre.js/reverb.html That is quite a large JavaScript framework, but maybe the right place to start? Looks interesting but it doesn't have support for ogg afaict. However I might be able to do something with the examples. Anyone else have any other suggestions? Am 10/13/2013 06:58 PM, schrieb Patrick Shirkey: Hi, Can anyone point me to an example for echo/delay/reverb filters using html5 audio? -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK + PA Latency
On Mon, September 30, 2013 9:50 pm, Fons Adriaensen wrote: On Sun, Sep 29, 2013 at 08:19:08PM -0400, Paul Davis wrote: There is no difference between jack_iodelay and *older* versions of Fons' original jack_delay, other than the formatting of the output. He has noted in the past that we should upgrade the code in jack's utility folder to use his newer version. As long as you measure a delay that is * independent of frequency in the range (approx) FS/64 up to FS/16, * constant or slowly changing both versions will measure the same. The newer version will be more tolerant if those conditions are not satisfied, which is certainly the case here (the delay seems to increase in a non- continuous way). Delay is calculated for phase measurements on a series of sine waves which have frequencies chosen to have some mathematical properties. The basic measurement is done at FS/16. This provides a delay D in the range [0...16) samples. The real delay is D + k * 16 samples, with k integer. The other frequencies do not affect precision, but are used to find the value of k. The original version used 4 such frequencies, each of them multiplying the unambiguous range by a factor of 8. The first one will add k_1 * 16 samples, the second k_2 * 128 samples and so on, with k_1...k4 integers in the range 0..7. The phase measurements provide a value in the range [0..8) which is then rounded to the nearest integer. This means that any error must be smaller than 360/16 degrees, or the wrong k_n will result. The new version uses 12 frequencies, each of them doubling the range. This will produce the correct result if phase errors are less than 360/4 degrees. For a good signal, the values computed from those frequencies will be close to an integer. The difference is tested, and if greater than 0.2 the result is flagged as suspect or rejected. When the delay is changing in steps (as is the case here), it's easy to get values that are inconsistent. Thanks for that explanation. IIUC the variation is making it harder to get a good reading. So the next step is figuring out why/where the variation is happening in the first place. It could just be this machine that is causing the inconsistent results or it could be something in the multitude of code that is being touched in order to send a stream from jack_delay - pa -ecasound -pa - jack_delay. This is why I ask for some more feedback from the LAD community. I have written up a guide on the test process that I am using. http://boosthardware.com/pa-jack-latency-test.txt I'm asking for additional suggestions on how to authoritatively test this combination and provide definitive results. I realise that it is a fairly difficult question but it is part of a big push for wider adoption of open source pro audio solutions so I hope that you will all feel it is worth the effort to solve this problem too. What I'm currently looking at is a tool that will measure the latency between each node in the graph. Possibly extending jack_delay for that purpose. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK + PA Latency
On Mon, September 30, 2013 11:30 pm, Fons Adriaensen wrote: On Mon, Sep 30, 2013 at 10:15:24PM +1000, Patrick Shirkey wrote: I'm asking for additional suggestions on how to authoritatively test this combination and provide definitive results. I realise that it is a fairly difficult question but it is part of a big push for wider adoption of open source pro audio solutions so I hope that you will all feel it is worth the effort to solve this problem too. In a system such as the one you are testing latency is determined by the amount of buffering, and nothing else. C-states shouldn't enter in the picture as long as the CPU wakeup time is a small fraction of a period (1.333ms in this case). If the wakeup time is too high, the whole setup just fails. In other words, if you measure e.g. 100ms of latency, that can only mean that somewhere along the pipeline 100ms of audio is being stored. It can't be the result of a CPU being 100ms late - that would interrupt the signal instead. The graph is about as simple as I can get it without writing a custom app. jack_delay - pa source pa_source - PA Stream Buffer PA Stream Buffer - alsa alsa - ecasound in ecasound in - ecasound out ecasound out - alsa alsa - PA Stream Buffer PA Stream Buffer - pa_sink pa_sink - jack_delay The most obvious potential violator is the bridge code between PA and ALSA because it's the one place that no one really seems to understand well at the moment. Does anyone here have experience with that code/functionality? -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK + PA Latency
On Tue, October 1, 2013 1:39 am, Paul Davis wrote: On Mon, Sep 30, 2013 at 11:33 AM, Fons Adriaensen f...@linuxaudio.orgwrote: On Tue, Oct 01, 2013 at 12:04:37AM +1000, Patrick Shirkey wrote: The most obvious potential violator is the bridge code between PA and ALSA because it's the one place that no one really seems to understand well at the moment. That would then affect *all* apps using PA via ALSA (which seems to be the only way)... I still don't understand the purpose of all this. An application that can't use Jack can still connect to it using the ALSA jack plugin, you don't need PA for this. A quick test here shows that the latency in that case is as solid as it gets. the linux mobile world has partially adopted PA as a native audio API (something PA's designer did not intend to happen). there are audio device streams that are accessible only via PA, much as FFADO is (or was) the only way in or out of a firewire device. even without this, there are control issues (related to audio session management, i.e. when one app has to be suspended). this may or may not have something to do with it. It has a lot to do with it. Bypassing PA is fine for desktop users who choose that method but it is not going to happen without major struggle and a large amount of resistance from several angles on Mobile platforms. Adding all of the above into JACK or making that functionality accessible while using JACK is unlikely to be viable for a number of fairly obvious reasons. Whereas ensuring that PA and JACK work as efficiently as technically possible IMO is an attainable and worthy goal which also makes the whole Linux Audio Stack more reliable and powerful. Either way we are not going to be able to *easily* run JACK on various mobile platforms until we address the issues. This is not my opinion, it is a stated fact coming directly from the people who are in charge of deciding the direction of Mobile Audio on such platforms. That makes it harder for open source multimedia to move onto those platforms and denies us the true potential of JACK on mobile until we do. FYI, the people I am in contact with are very supportive of the goal of running JACK and the possibilities therein but they are not going to open the door until various issues are resolved. Currently the priority is establishing some hard data on the total latency of the PA+JACK combination. We have got close with these tests and the good news is that we are in the same space as the current best that Android can offer. However, it can be better, more stable and we can definitely go lower. Anyway this thread is not supposed to be a discussion on for or against, it is about isolating the bottlenecks in the graph. It seems that I am the only person in the world who has the time/motivation to test the combination of PA+JACK. I only have access to one computer at this time to run the tests. Therefore we only have one data set to work from. The issues I am seeing could turn out to be entirely local in which case we would be wasting time to try and fix things that are not actually broken. At this point it would be very helpful to get some additional test results from the rest of the LAD/LAU community. Apparently I have to beg people to do that these days or maybe people are waiting for me to offer some kind of financial reward? Apparently being able to run JACK *and* sell apps on several mobile platforms is not enough incentive. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK + PA Latency
On Sat, September 28, 2013 6:53 am, Fons Adriaensen wrote: On Sat, Sep 28, 2013 at 03:09:36AM +1000, Patrick Shirkey wrote: The results are quite different so that's a good sign. However they are still changing on a regular basis so my quest to understand the cause of this behaviour to find out if it is a localised issue or a bug of some kind is not over yet. I'd say you have two ways to find out: 1. Get the PA sources and rip them apart, 2. Get the PA authors and make them sing (or rip them apart as well). The PA Devs are aware of my results and have been very helpful so far. We are getting into a murky area where the code has not been worked on recently so it takes time to refresh on the specifics. With the differing results from jack_iodelay and jack_delay that has unfortunately thrown a spanner in the works. Now I have to *prove* that the new results are completely reliable. That's not an attack on your work, just that now I have a new variation that needs to be fully explained to make sure there is no doubt, otherwise it's likely that fingers will point in other directions. Some additional empirical data and test results from other people will be helpful too. I have compiled the test procedure into a basic document now: http://boosthardware.com/pa-jack-latency-test.txt To recap some of the results so far are : - The combination of JACK + PA is stable on my machine for several days in a row even at 64 frames/period and using hda_intel onboard device - PA Stream Buffer can give consistent 10ms latency - I am now seeing latency between 16ms to 75ms with the new version of jack_delay - There appears to be a bug in the official jack_iodelay which is part of the jack utility app suite. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] JACK + PA Latency
roundtrip latency extra loopback latency: 65088 frames use 32544 for the backend arguments -I and -O 65087.999 frames 1356.000 ms total roundtrip latency extra loopback latency: 65087 frames use 32543 for the backend arguments -I and -O 65152.000 frames 1357.333 ms total roundtrip latency extra loopback latency: 65151 frames use 32575 for the backend arguments -I and -O 65152.000 frames 1357.333 ms total roundtrip latency extra loopback latency: 65151 frames use 32575 for the backend arguments -I and -O 65152.000 frames 1357.333 ms total roundtrip latency extra loopback latency: 65152 frames use 32576 for the backend arguments -I and -O 65152.000 frames 1357.333 ms total roundtrip latency extra loopback latency: 65151 frames use 32575 for the backend arguments -I and -O 65216.000 frames 1358.667 ms total roundtrip latency extra loopback latency: 65216 frames use 32608 for the backend arguments -I and -O 64.000 frames 1.333 ms total roundtrip latency extra loopback latency: 63 frames use 31 for the backend arguments -I and -O 64.000 frames 1.333 ms total roundtrip latency extra loopback latency: 63 frames use 31 for the backend arguments -I and -O ?? Inv 256.000 frames 5.333 ms total roundtrip latency extra loopback latency: 256 frames use 128 for the backend arguments -I and -O 256.000 frames 5.333 ms total roundtrip latency extra loopback latency: 256 frames use 128 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 639 frames use 319 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 639 frames use 319 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 639 frames use 319 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 639 frames use 319 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 640.000 frames 13.333 ms total roundtrip latency extra loopback latency: 640 frames use 320 for the backend arguments -I and -O 768.001 frames 16.000 ms total roundtrip latency extra loopback latency: 768 frames use 384 for the backend arguments -I and -O 832.000 frames 17.333 ms total roundtrip latency extra loopback latency: 832 frames use 416 for the backend arguments -I and -O 832.000 frames 17.333 ms total roundtrip latency extra loopback latency: 832 frames use 416 for the backend arguments -I and -O 832.000 frames 17.333 ms total roundtrip latency extra loopback latency: 831 frames use 415 for the backend arguments -I and -O 832.000 frames 17.333 ms total roundtrip latency extra loopback latency: 832 frames use 416 for the backend arguments -I and -O 1024.000 frames 21.333 ms total roundtrip latency extra loopback latency: 1024 frames use 512 for the backend arguments -I and -O ?? 1024.000 frames 21.333 ms total roundtrip latency extra loopback latency: 1024 frames use 512 for the backend arguments -I and -O 1024.000 frames 21.333 ms total roundtrip latency extra loopback latency: 1023 frames use 511 for the backend arguments -I and -O 1024.000 frames 21.333 ms total roundtrip latency extra loopback latency: 1023 frames use 511 for the backend arguments -I and -O 1344.000 frames 28.000 ms total roundtrip latency extra loopback latency: 1344 frames use 672 for the backend arguments -I and -O -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK + PA Latency
On Sat, September 28, 2013 1:29 am, Fons Adriaensen wrote: On Sat, Sep 28, 2013 at 12:42:26AM +1000, Patrick Shirkey wrote: 1: Why PA is reporting 10ms for the stream buffer but jack_delay is giving the results below. 2: Why PA is reporting 10ms for the stream buffer when I am running jack at 64 frames/period and ecasound too. 3: Where the fluctuating measurements from jack_delay are coming from in the graph as PA Stream Buffer is static at 10ms and ecasound is basically in pass through with a 64/48k buffer same as JACK. A back of the envelop estimation suggests latency should be stable well under 20ms including the 10ms set aside for the PA Stream buffer. (1) and (2) you should really ask to the PA author(s). Regarding (3): * The results you included can't be consecutive outputs of jack_iodelay at least not as I wrote it. So what is the real timing of them ? Those results are sequentially copied with no editing. I was surprised to see it as I thought it would just keep climbing. I have included the full log here: http://boosthardware.com/pa-jack-latency-1.txt Absolutely no editing. * How is ecasound taling to PA ? Some native PA interface ? ALSA ? Any ALSA 'plugs' in the chain ? ecasound -f:32,2,48000 -b:64 -i alsa -o alsa It's possible that something is creeping in between ecasound and PA. Or maybe it is the way PA is handling the stream? * Going from 65216 to 64 is just an overflow modulo 2^16 (which the maximum that jack_(io)delay can measure. Apart from that, the delay seems to be continuously increasing, but since you edited the result it's not possible to say how fast. Either PA is adding more and more buffering as time goes on, or it is resampling and doing a very bad job at it. Hint: use jack_delay (on my website), it will output less clutter (one line per value), and is also more resistant to abnormal circumstances. I will try that next. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] JACK + PA Latency
On Sat, September 28, 2013 2:47 am, Patrick Shirkey wrote: On Sat, September 28, 2013 1:29 am, Fons Adriaensen wrote: On Sat, Sep 28, 2013 at 12:42:26AM +1000, Patrick Shirkey wrote: 1: Why PA is reporting 10ms for the stream buffer but jack_delay is giving the results below. 2: Why PA is reporting 10ms for the stream buffer when I am running jack at 64 frames/period and ecasound too. 3: Where the fluctuating measurements from jack_delay are coming from in the graph as PA Stream Buffer is static at 10ms and ecasound is basically in pass through with a 64/48k buffer same as JACK. A back of the envelop estimation suggests latency should be stable well under 20ms including the 10ms set aside for the PA Stream buffer. (1) and (2) you should really ask to the PA author(s). Regarding (3): * The results you included can't be consecutive outputs of jack_iodelay at least not as I wrote it. So what is the real timing of them ? Those results are sequentially copied with no editing. I was surprised to see it as I thought it would just keep climbing. I have included the full log here: http://boosthardware.com/pa-jack-latency-1.txt Absolutely no editing. * How is ecasound taling to PA ? Some native PA interface ? ALSA ? Any ALSA 'plugs' in the chain ? ecasound -f:32,2,48000 -b:64 -i alsa -o alsa It's possible that something is creeping in between ecasound and PA. Or maybe it is the way PA is handling the stream? * Going from 65216 to 64 is just an overflow modulo 2^16 (which the maximum that jack_(io)delay can measure. Apart from that, the delay seems to be continuously increasing, but since you edited the result it's not possible to say how fast. Either PA is adding more and more buffering as time goes on, or it is resampling and doing a very bad job at it. Hint: use jack_delay (on my website), it will output less clutter (one line per value), and is also more resistant to abnormal circumstances. I will try that next. http://boosthardware.com/pa-jack-latency-2.txt The results are quite different so that's a good sign. However they are still changing on a regular basis so my quest to understand the cause of this behaviour to find out if it is a localised issue or a bug of some kind is not over yet. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] who wants contribute to Advanced Gtk+ Sequencer
On Wed, September 25, 2013 1:01 am, Joël Krähemann wrote: Hi, I'm writing a software synth/sequencer called Advanced Gtk+ Sequencer. It won't take much time till first pre-release 0.4.0 I got basic functions working. Now I'm pleased to ask if someone wants to contribute. Looks like an interesting project. Note pulseaudio interferes with Advanced Gtk+ Sequencer to achieve best results I even recommend WindowMaker as desktop or any minimal window manager of your choice. Do you have any specific issues that you would like to flag? http://sourceforge.net/projects/ags/ If your asking yourself how to use Advanced Gtk+ Sequencer please take a look at a screencast I just made this morning on Google+ The project features a wiki with some programming howtos and explanation of internals. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Screencasting with JACK [SOLVED!]
On Fri, August 9, 2013 12:58 pm, J. Liles wrote:
On Thu, Aug 8, 2013 at 6:54 PM, J. Liles malnour...@gmail.com wrote:
As some of you may recall, every time I've posted a demo video to LAD,
I've had to include a disclaimer excusing the poor quality due to a lack
of
functional screencasting tools.
Well, it took a couple of weeks of hair pulling and many, many hours of
testing, but I finally arrived at a solution.
Anyone who wants to create a screencast and record audio via JACK *in
perfect sync* must do the following:
Get ffmpeg. Apply this patch to it:
https://github.com/original-male/FFmpeg/commit/d02509d04d396a98646ca81e9ba327a501486130.patch
Build it with vorbis and h264 support.
Then, start your favorite desktop environment. I use Xephyr for this.
Have jack running (at -r 48000)
Then run the following command:
ffmpeg -fflags +genpts+igndts -f x11grab -vsync 0 -r 30 -s 1920x1080 -i
:${DISPLAY}.+0,0 -vcodec h264 -f jack -ac 2 -r:a 48000 -i screencast
-acodec pcm_s16le -r:v 30 -vsync 2 -async 1 -map 0:0,1,0 -map 1:0
-preset
ultrafast -qp 0 $FILE
Where DISPLAY is the number of your X11 display and FILE is the filename
for the screencast. I use a .mkv extension for the matroska container.
Remember to connect the streams you want recorded to the 'screencast'
JACK
inputs!
With this setup I'm able to record a full 30 FPS @ 1080P with audio in
perfect sync. Please share your results too. With some more evidence I
might have a good case to get ffmpeg to accept my patch.
They are pretty helpful folks and will give you useful feedback if you
submit the patch and they see any issues.
Enjoy!
Forgot to mention, use at least these options when configuring ffmpeg:
./configure --enable-libx264 --enable-x11grab --enable-gpl
--enable-libvorbis
It would be interesting to have an app for this... Similar to Time
Machine. Just a big button that automatically saves the past x mins.
If you are interested let me know. I think I can find some time for that.
--
Patrick Shirkey
Boost Hardware Ltd
___
Linux-audio-dev mailing list
Linux-audio-dev@lists.linuxaudio.org
http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] build troubles with gtklick
On Mon, April 8, 2013 8:38 pm, Jörn Nettingsmeier wrote: dominic, ralf, thanks for this hint, however... On 04/08/2013 02:39 AM, Dominique Michel wrote: Le Mon, 08 Apr 2013 01:16:37 +0200, Jörn Nettingsmeier netti...@stackingdwarves.net a écrit : File /usr/lib/python2.7/site-packages/gtklick/klick_backend.py, line 12, in module import liblo ImportError: /usr/lib64/python2.7/site-packages/liblo.so: undefined symbol: lo_address_new_with_proto i have tried both liblo-0.26 and current liblo svn, no luck. now the python paths in this openSUSE tumbleweed install are a horrible mess, with three different python versions and libs in /usr/lib, /usr/lib64, and /usr/local/lib64. but they all seem to be found, and i made sure that the liblo.so mentioned in the error message is actually the one from your pyliblo package (by copying it manually). i removed the build directory of pyliblo for each try, and also recreated liblo.c via cython. how do i proceed to fix this? python is a mess in itself because we have python 2 and 3, and the shebang of many python programs is set as #!/usr/bin/python, which doesn't tell the system which version to use. You have to adjust the shebangs so that the scripts will use the correct version. Something like #!/usr/bin/python2.7 i've tried both python2 and python2.7 in the hashbang. but the error remains the same. to me it looks like a pyliblo/liblo version mismismatch, but i'm not sure Why not run it in virtualenv and bypass the suse packaging library system? -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] RFP: Channel Linux - BETA
mean? We need content, lots of it. We need constructive feedback and suggestions for making the site really hit the sweet spot of usability and entertainment. And we need your links, tweets, facebook likes and passionate evangelism to help us grow the traffic to the kind of numbers that companies with serious cash are prepared to spend their money on. We have the capacity if we choose to use it. I hope you are prepared for the ride :-) -- Patrick Shirkey Boost Digital / Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Promoting Linux Companies
Hi, If you have a Linux oriented company that would like to receive some free promotion to a global audience please get in touch with me directly. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Floss alternative to red5
On Thu, February 28, 2013 8:16 pm, APO33 wrote: Hi Jonathan, Jeremy, Patrick, We are testing a lot webRTC of course! it's seems one of the main amazing AV web developpement because of html5 being such easy and great, should we say futur standard or is it already one? Also do you think html5 and the work of access local and display could be implemented without webRTC with getUserMedia(, createObjectURL? and for example only use the audio... I am watching the conference at the moment, mayeb she have the answer?!! I am wondering if we could also combined gstreamer+html5 (or other audio good floss software) on a server... Yes it is possible t use gstreamer or icecast, shoutcast. So for you webRTC is THE solution for AV web based project alternative to red5 and flash? It's the open standard which is being promoted by Google, Apple, Mozilla, etc... You can feel confident that it will not be a waste of your time to build with it. Is anyone have tested anything using python or java? It is trivial to produce html5 with python or java. What specific functionality are you planning/looking for? thank for your answers! cheers Julien On 02/26/2013 11:40 PM, APO33 wrote: The idea is that the final user will stream his sound and video with his browser and everyone could see/hear him and do the same via their browser. Did you already take a look at the possibilities of WebRTC? http://www.html5rocks.com/en/tutorials/webrtc/basics/ There was also a presentation by Silvia Pfeiffer at linux.conf.au about the use of WebRTC to do non-centralised video conferencing. It was at 10:40 in MCC3 on Wednesday if you are looking at the program at http://lca2013.linux.org.au/programme/schedule At some point the videos and slides will be linked to this, but in the meantime the abstract can be found here: http://lca2013.linux.org.au/schedule/30040/view_talk?day=None The video is currently available at http://mirror.linux.org.au/linux.conf.au/2013/ogv/Code_up_your_own_video_conference_in_HTML5.ogv or other formats (webm, mp4) at http://mirror.linux.org.au/linux.conf.au/2013/ Regards jonathan -- APO33 space of research and experimentation http://www.apo33.org i...@apo33.org ___ 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
Re: [LAD] Floss alternative to red5
On Fri, March 1, 2013 1:04 am, Jeremy Jongepier wrote: On 02/28/2013 12:28 PM, Patrick Shirkey wrote: On Thu, February 28, 2013 8:16 pm, APO33 wrote: Hi Jonathan, Jeremy, Patrick, We are testing a lot webRTC of course! it's seems one of the main amazing AV web developpement because of html5 being such easy and great, should we say futur standard or is it already one? It's still a draft. Also do you think html5 and the work of access local and display could be implemented without webRTC with getUserMedia(, createObjectURL? and for example only use the audio... No idea, should be possible I guess. I am watching the conference at the moment, mayeb she have the answer?!! I am wondering if we could also combined gstreamer+html5 (or other audio good floss software) on a server... Yes it is possible t use gstreamer or icecast, shoutcast. So for you webRTC is THE solution for AV web based project alternative to red5 and flash? For me it is. At work we're already using it in pilots with clients (videocalling) and so far it works better than any Flash-based solution. It's the open standard which is being promoted by Google, Apple, Mozilla, etc... You can feel confident that it will not be a waste of your time to build with it. Afaik Apple is not involved. Besides, they would want H264 as the standard videocodec, not VP8. s/Apple/Samsung|Intel/ Bah they all look the same these days anyway ;-) -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Floss alternative to red5
On Thu, February 28, 2013 10:22 am, Jonathan Woithe wrote: On 02/26/2013 11:40 PM, APO33 wrote: The idea is that the final user will stream his sound and video with his browser and everyone could see/hear him and do the same via their browser. Did you already take a look at the possibilities of WebRTC? http://www.html5rocks.com/en/tutorials/webrtc/basics/ There was also a presentation by Silvia Pfeiffer at linux.conf.au about the use of WebRTC to do non-centralised video conferencing. It was at 10:40 in MCC3 on Wednesday if you are looking at the program at http://lca2013.linux.org.au/programme/schedule At some point the videos and slides will be linked to this, but in the meantime the abstract can be found here: http://lca2013.linux.org.au/schedule/30040/view_talk?day=None The video is currently available at http://mirror.linux.org.au/linux.conf.au/2013/ogv/Code_up_your_own_video_conference_in_HTML5.ogv or other formats (webm, mp4) at http://mirror.linux.org.au/linux.conf.au/2013/ In case you would like to also have some 3d functionality I just came across this example for using webrtc with threejs* http://stemkoski.github.com/Three.js/ See the webcamtest and webcam texture examples. *https://github.com/mrdoob/three.js/wiki Has some interesting possibilites for browser based 3d multimedia. 3js will also load exported blender models for rapid game development. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] python, gtk, gstreamer
On Thu, February 28, 2013 1:37 pm, drew Roberts wrote: On Wednesday 27 February 2013 18:51:34 Patrick Shirkey wrote: On Thu, February 28, 2013 8:14 am, drew Roberts wrote: Ignorant here. Trying to scrounge around and make something work for a demo purpose. In python I am trying to build this pipeline: pipeline_txt = ( 'jackaudiosrc ! ' 'level name=level interval=10 !' 'jackaudiosink') pipeline = gst.parse_launch(pipeline_txt) I have been trying that a number of ways. So, I basically watch the bus for level info. In a subroutine, I can print the peak info to the terminal. I can't seem to figure out how to pass this info back to the rest of the program so that I can hook it up to a graphical meter. Add a call to the callback for the meter to set the meter value from the subroutine? Cna anyone point me to some simple code doing something like this? Give me some clues that might help someone who seems to be being very dense for days now? Sounds like you just need to connect the meter to the subroutine but it's a bit had to say without a bit more code to demonstrate how you are setting up the meter. A few questions... Is the meter a class of it's own or just a widget in a draw routine? Do you have a set_meter_value type of function or are you just calling directly to the meter widget's value? What UI toolkit is the meter using? Right now, I have not even tried to make a meter, I just want to get the peak value out of the subroutine and print it from outside. I can print it from the inside but can't even figure out how to get it out. One sample I started working with (there are others but this is one) can be found here: http://stackoverflow.com/questions/9344888/getting-max-amplitude-for-an-audio-file-per-second In the def show_peak(bus, message): there is: peaks.append(message.structure['peak'][0]) but this is more of a batch type setup rather than an interactive one. So let's say I do something like this instead: #peaks.append(message.structure['peak'][0]) zpeak = message.structure['peak'][0] #print message.structure: print zpeak return zpeak along with making a jack source and sink instead of a file source and fake sink. I can get the peaks printed in there via the print zpeak. But I am going around in circles (actually, circles is too clean a shape) in my head trying to figure out how to get that info out as it comes in. Once I ge that, then I have to figure out how to hook it up to a meter widget. One possibility I have looked at basing this on is this: http://zetcode.com/gui/pygtk/customwidget/ A custom gtk/cairo widget is pretty easy to update. You have a draw method in the widget class and call widget_queue_redraw(widget) when you want to refresh the widget. You can set the widget's data before the call to widget_queue_redraw() With the peak data you can use a timer or loop to update a callback that sets the meter widget's data then calls the redraw command. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Interoperability between session management systems
On Sun, February 24, 2013 6:05 am, David Robillard wrote: On Sat, 2013-02-23 at 17:01 +0100, Johannes Kroll wrote: A couple of days ago, I tried out non-session-manager, and thought, this is really nice. It really works in a practical, easy way. Unfortunately the number of apps supporting non-session is quite small (as is the case for *all* session management systems, AFAIK). There may be a complete audio studio supporting non-session, from one choice of sequencer to one synth to one sampler, but people like to use their favorite software. You can't just say, if you want to use a sequencer, use X because it supports non-session. So its usefulness is limited. However, many apps support one session management framework or the other. So the obvious thing to do if you want to give people more choices would be to create some kind of interoperability layer between session management systems. What do you think about this? Is there an effort for something like this already underway? I personally think a good first step might be to create some compatibility between non-session (because I like it) and jack-session (because most people are using jack). I was tinkering with saving sessions in a format that is just a directory with a shell script with a standard name (and perhaps some standard arguments) which you call to restore or do other things. Not sure if that's a really feasible solution in general, but it's basically the only way to save sessions in a way that don't require a specific session manager to load, and doesn't impose any file formats. Actually being able to restore sessions decently from a script requires a few more sophisticated jack command line utilities (like a jack_connect that can wait for clients and so on), but those are useful anyway. I like the lowest common denominator, and UNIXeyness, and zero imposition of syntax and so on, of this idea, but haven't really investigated it or done much of an implementation. Being based purely on classic UNIXisms (directory and a script that calls some utilities is all that's going on) is probably the only way to actually get everybody to agree on such a thing. Standardization of such a spec would only involved command line utilities/arguments, paths, and environment variables. Thanks to the shebang mechanism, it would be language agnostic as well. Personally I have no plans to prioritize this, but I think it's an interesting area to explore. Why do applications need to support a specific session manager? The session manager just calls the JACK API to notify a client app that an update is required to the internal state. What else is there to bother with on the application side? -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] C/gtk3/cairo meter widget
On Tue, February 12, 2013 9:00 pm, SxDx wrote: On 02/12/2013 09:56 AM, Patrick Shirkey wrote: On Tue, February 12, 2013 3:50 am, Paul Davis wrote: On Mon, Feb 11, 2013 at 11:44 AM, Patrick Shirkey pshir...@boosthardware.com wrote: Thanks for the tip. Will save me some braincells. Found it here: http://guitarix.sourcearchive.com/documentation/0.10.0-2/GtkFastMeter_8cpp-source.html http://guitarix.sourcearchive.com/documentation/0.10.0-2/GtkFastMeter_8h-source.html the code in ardour3 doesn't use pixbufs and is entirely drawn directly with cairo. you may or may not care. It's a multistep process to get it all integrated. I couldn't find anything specific online for making a custom widget with gtk3 so I have copied the structure and methods from the gtkscale/gtkrange widgets. http://git.gnome.org/browse/gtk+/tree/gtk/gtkscale.c?h=gtk-3-6 http://git.gnome.org/browse/gtk+/tree/gtk/gtkrange.c?h=gtk-3-6 I got it to the point where it the class is building and init() is being called but I am having a problem with assigning the correct TYPE for GTK_METER and getting the draw/realize methods to fire. http://boosthardware.com/code/jamin/ Can you provide a small main.c or something? All I see in there are static init functions never called. Yeah it's just the class, no wrapping. It can be called like this: GtkWidget *gtkmeter; GtkAdjustment *adjustment = (GtkAdjustment*) gtk_adjustment_new(0.0, -40, 6, 0.0, 0.0, 0.0); meter = gtk_meter_net(adjustment, GTK_METER_UP, 0. -40, 6); -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] C/gtk3/cairo meter widget
On Thu, February 14, 2013 3:43 am, Patrick Shirkey wrote: On Tue, February 12, 2013 9:00 pm, SxDx wrote: On 02/12/2013 09:56 AM, Patrick Shirkey wrote: On Tue, February 12, 2013 3:50 am, Paul Davis wrote: On Mon, Feb 11, 2013 at 11:44 AM, Patrick Shirkey pshir...@boosthardware.com wrote: Thanks for the tip. Will save me some braincells. Found it here: http://guitarix.sourcearchive.com/documentation/0.10.0-2/GtkFastMeter_8cpp-source.html http://guitarix.sourcearchive.com/documentation/0.10.0-2/GtkFastMeter_8h-source.html the code in ardour3 doesn't use pixbufs and is entirely drawn directly with cairo. you may or may not care. It's a multistep process to get it all integrated. I couldn't find anything specific online for making a custom widget with gtk3 so I have copied the structure and methods from the gtkscale/gtkrange widgets. http://git.gnome.org/browse/gtk+/tree/gtk/gtkscale.c?h=gtk-3-6 http://git.gnome.org/browse/gtk+/tree/gtk/gtkrange.c?h=gtk-3-6 I got it to the point where it the class is building and init() is being called but I am having a problem with assigning the correct TYPE for GTK_METER and getting the draw/realize methods to fire. http://boosthardware.com/code/jamin/ Can you provide a small main.c or something? All I see in there are static init functions never called. Yeah it's just the class, no wrapping. It can be called like this: GtkWidget *gtkmeter; GtkAdjustment *adjustment = (GtkAdjustment*) gtk_adjustment_new(0.0, -40, 6, 0.0, 0.0, 0.0); meter = gtk_meter_net(adjustment, GTK_METER_UP, 0. -40, 6); Turns out there were a couple of small items that needed to be changed. I had to disable the additional params in the call to g_object_new() in gtk_meter_init() and fix the Type Declaration. I have updated the files.http://boosthardware.com/code/jamin/ At the moment I have a meter that doesn't update which shouldn't take long to fix. However what I am aiming for is to integrate the different cairo meters into one class. fastmeter - ardour vumeter - scenic GtkMeter - jackeq Any ideas or suggestions on how to make that work for the GtkMeter class? -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] C/gtk3/cairo meter widget
On Thu, February 14, 2013 9:15 am, Tristan Matthews wrote: 2013/2/13 Patrick Shirkey pshir...@boosthardware.com: On Thu, February 14, 2013 3:43 am, Patrick Shirkey wrote: On Tue, February 12, 2013 9:00 pm, SxDx wrote: On 02/12/2013 09:56 AM, Patrick Shirkey wrote: On Tue, February 12, 2013 3:50 am, Paul Davis wrote: On Mon, Feb 11, 2013 at 11:44 AM, Patrick Shirkey pshir...@boosthardware.com wrote: Thanks for the tip. Will save me some braincells. Found it here: http://guitarix.sourcearchive.com/documentation/0.10.0-2/GtkFastMeter_8cpp-source.html http://guitarix.sourcearchive.com/documentation/0.10.0-2/GtkFastMeter_8h-source.html the code in ardour3 doesn't use pixbufs and is entirely drawn directly with cairo. you may or may not care. It's a multistep process to get it all integrated. I couldn't find anything specific online for making a custom widget with gtk3 so I have copied the structure and methods from the gtkscale/gtkrange widgets. http://git.gnome.org/browse/gtk+/tree/gtk/gtkscale.c?h=gtk-3-6 http://git.gnome.org/browse/gtk+/tree/gtk/gtkrange.c?h=gtk-3-6 I got it to the point where it the class is building and init() is being called but I am having a problem with assigning the correct TYPE for GTK_METER and getting the draw/realize methods to fire. http://boosthardware.com/code/jamin/ Can you provide a small main.c or something? All I see in there are static init functions never called. Yeah it's just the class, no wrapping. It can be called like this: GtkWidget *gtkmeter; GtkAdjustment *adjustment = (GtkAdjustment*) gtk_adjustment_new(0.0, -40, 6, 0.0, 0.0, 0.0); meter = gtk_meter_net(adjustment, GTK_METER_UP, 0. -40, 6); Turns out there were a couple of small items that needed to be changed. I had to disable the additional params in the call to g_object_new() in gtk_meter_init() and fix the Type Declaration. I have updated the files.http://boosthardware.com/code/jamin/ At the moment I have a meter that doesn't update which shouldn't take long to fix. However what I am aiming for is to integrate the different cairo meters into one class. fastmeter - ardour vumeter - scenic GtkMeter - jackeq I would recommend avoiding subclassing, if possible, and maybe install a render-style property for your object which will determine which drawing code to call. Maybe it's not as easy as that though. That can be done. Just need a switch for the different draw code. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] C/gtk3/cairo meter widget
Hi, FYI, I have updated the class with some basic structure for adding different cairo drawing functions. If anyone wants to take a look at the code and make improvements feel free. I haven't added the fastmeter logic yet. http://boosthardware.com/code/jamin/ You can call it like this: #include gtkmeter.h GtkWidget *gtkmeter; GtkAdjustment *adjustment = (GtkAdjustment*) gtk_adjustment_new(0.0, -40, 6, 0.0, 0.0, 0.0); meter = gtk_meter_net(adjustment, GTK_METER_UP, GTK_METERSCALE_TOP. -40, 6); gtk_meter_set_adjustment(GTK_METER (meter), adjustment); - I have added it to the gtk3 port of JAMin which you can download from http://jamin.sf.net to see it in action. It's all in the git repo. Check these files for more advanced examples: callbacks.c interface.c gtkmeter.c intrim.c compressor-ui.c I'll put together a README when I have some more time. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] C/gtk3/cairo meter widget
On Tue, February 12, 2013 3:50 am, Paul Davis wrote: On Mon, Feb 11, 2013 at 11:44 AM, Patrick Shirkey pshir...@boosthardware.com wrote: Thanks for the tip. Will save me some braincells. Found it here: http://guitarix.sourcearchive.com/documentation/0.10.0-2/GtkFastMeter_8cpp-source.html http://guitarix.sourcearchive.com/documentation/0.10.0-2/GtkFastMeter_8h-source.html the code in ardour3 doesn't use pixbufs and is entirely drawn directly with cairo. you may or may not care. It's a multistep process to get it all integrated. I couldn't find anything specific online for making a custom widget with gtk3 so I have copied the structure and methods from the gtkscale/gtkrange widgets. http://git.gnome.org/browse/gtk+/tree/gtk/gtkscale.c?h=gtk-3-6 http://git.gnome.org/browse/gtk+/tree/gtk/gtkrange.c?h=gtk-3-6 I got it to the point where it the class is building and init() is being called but I am having a problem with assigning the correct TYPE for GTK_METER and getting the draw/realize methods to fire. http://boosthardware.com/code/jamin/ If anyone feels like chipping in some suggestions for how to get past this step I'm all ears :-) http://developer.gnome.org/gobject/stable/howto-interface-implement.html http://developer.gnome.org/gobject/stable/gobject-Type-information.html -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] C/gtk3/cairo meter widget
On Tue, February 12, 2013 12:15 am, James Warden wrote: On Sun, Feb 10, 2013 at 11:36 PM, Patrick Shirkey pshir...@boosthardware.com wrote: On Mon, February 11, 2013 3:21 pm, Paul Davis wrote: On Sun, Feb 10, 2013 at 11:16 PM, Patrick Shirkey pshir...@boosthardware.com wrote: On Mon, February 11, 2013 9:47 am, Tristan Matthews wrote: 2013/2/10 Patrick Shirkey pshir...@boosthardware.com Therè's this one: https://github.com/sat-metalab/scenic/blob/master/src/vumeter/vumeter.cpp https://github.com/sat-metalab/scenic/blob/master/src/include/vumeter.h It has only a few c++isms and could easily be purely in C. Thanks. It does look useful. Seems to be written for gtk2 though. Have you compiled it with gtk3? at the very least, it would need a draw() method rather than an expose() method. plus, if i read it correctly it also redraws its entire self (subject to cairo clipping) on every expose. contrast with the the fastmeter in ardour3's libs/gtkmm2ext which draws only the changed pixels per expose. I would prefer to use that but it's in pure C++ as well as GTK2 so I have to convert it to c and gtk3 :-( Back in the days I had time to help Herman Meyer on his guitarix project, I imported ardour's fast meters into C. Guitarix was using the C version of gtk. You can look into the old guitarix code in sourceforge (that was a long while back, maybe 3-4 years). Thanks for the tip. Will save me some braincells. Found it here: http://guitarix.sourcearchive.com/documentation/0.10.0-2/GtkFastMeter_8cpp-source.html http://guitarix.sourcearchive.com/documentation/0.10.0-2/GtkFastMeter_8h-source.html -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] C/gtk3/cairo meter widget
On Mon, February 11, 2013 10:51 pm, Paul Davis wrote: On Sun, Feb 10, 2013 at 11:36 PM, Patrick Shirkey pshir...@boosthardware.com wrote: On Mon, February 11, 2013 3:21 pm, Paul Davis wrote: On Sun, Feb 10, 2013 at 11:16 PM, Patrick Shirkey pshir...@boosthardware.com wrote: On Mon, February 11, 2013 9:47 am, Tristan Matthews wrote: 2013/2/10 Patrick Shirkey pshir...@boosthardware.com Therè's this one: https://github.com/sat-metalab/scenic/blob/master/src/vumeter/vumeter.cpp https://github.com/sat-metalab/scenic/blob/master/src/include/vumeter.h It has only a few c++isms and could easily be purely in C. Thanks. It does look useful. Seems to be written for gtk2 though. Have you compiled it with gtk3? at the very least, it would need a draw() method rather than an expose() method. plus, if i read it correctly it also redraws its entire self (subject to cairo clipping) on every expose. contrast with the the fastmeter in ardour3's libs/gtkmm2ext which draws only the changed pixels per expose. I would prefer to use that but it's in pure C++ as well as GTK2 so I have to convert it to c and gtk3 :-( well it depends on what you want. tristan's has level markings etc. as part of the meter widget, and is very close to a pure C widget. mine has a very efficient and C-ish drawing method that was created with gtk3 in mind. its not exactly atypical to find that what you want doesn't exist and you have to blend bits and piece. Yeah looks like this is going to have to be done the hard way. The guitarix code is definitely in cCbut it also use gtk_drawable which means I have to convert it to cairo for gtk3. So, I guess I will integrate the cairo code from fastmeter with the almost c code from Tristans while using the guitarix port as a reference and trying to maintain the structure of hte original gtkmeter from JAMin :-) Oh yeah! -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] C/gtk3/cairo meter widget
Hi, Before I spend any time to rewrite the gtkmeter.c/h widget for JAMin to gtk3/cairo does anyone have one already finished? Needs to be in C. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] C/gtk3/cairo meter widget
On Mon, February 11, 2013 9:47 am, Tristan Matthews wrote: 2013/2/10 Patrick Shirkey pshir...@boosthardware.com Hi, Before I spend any time to rewrite the gtkmeter.c/h widget for JAMin to gtk3/cairo does anyone have one already finished? Needs to be in C. Therè's this one: https://github.com/sat-metalab/scenic/blob/master/src/vumeter/vumeter.cpp https://github.com/sat-metalab/scenic/blob/master/src/include/vumeter.h It has only a few c++isms and could easily be purely in C. Thanks. It does look useful. Seems to be written for gtk2 though. Have you compiled it with gtk3? -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] C/gtk3/cairo meter widget
On Mon, February 11, 2013 3:21 pm, Paul Davis wrote: On Sun, Feb 10, 2013 at 11:16 PM, Patrick Shirkey pshir...@boosthardware.com wrote: On Mon, February 11, 2013 9:47 am, Tristan Matthews wrote: 2013/2/10 Patrick Shirkey pshir...@boosthardware.com Therè's this one: https://github.com/sat-metalab/scenic/blob/master/src/vumeter/vumeter.cpp https://github.com/sat-metalab/scenic/blob/master/src/include/vumeter.h It has only a few c++isms and could easily be purely in C. Thanks. It does look useful. Seems to be written for gtk2 though. Have you compiled it with gtk3? at the very least, it would need a draw() method rather than an expose() method. plus, if i read it correctly it also redraws its entire self (subject to cairo clipping) on every expose. contrast with the the fastmeter in ardour3's libs/gtkmm2ext which draws only the changed pixels per expose. I would prefer to use that but it's in pure C++ as well as GTK2 so I have to convert it to c and gtk3 :-( -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] So what do you think sucks about Linux audio ?
On Wed, February 6, 2013 7:12 am, Paul Davis wrote: On Tue, Feb 5, 2013 at 2:26 PM, Louigi Verona louigi.ver...@gmail.comwrote: Here, on Linux, there is no such thing as market competition. And thus - no natural selection of software, so to speak. if and when bitwig is released for linux, i suspect this will not be the case anymore. One Ring to rule them all, One Ring to find them, One Ring to bring them all and in the darkness bind them... We already have market competition. AVID, Apple, Microsoft, AMD, Nokia and even Google actively work against anything the open source multimedia developers are throwing at them. Intel is on the fence. They have a large Linux department but don't make many contributions round here. We don't here from ARM much either but TI, Qualcomm do support their employees supporting this community. The strange thing is how many movie studios use our tools but are not actively contributing to the community. There is a pickup in radio stations though. However the bulk of the work that is done is privately funded or research projects. What sucks about Linux Audio is the guys who print as much money as they want don't like open source multimedia. They see it as an existential threat and do everything they can to cripple wider adoption of the tools, products and services that open source multimedia folks provide. Given that the Linux Audio Community is not in a position to fight on the same level we are always the underdog. If I had the ability to print billions of dollars and rack up trillions of dollars of debt with my Hereditary Bankster Elite Buddies things would be very different for Open Source Multimedia. If we didn't have to compete with Government organisations backed by unlimited funds to make a sale of our products we would be very busy. In the meantime I have to feed my kids and pay the rent like every other Joe who is not a member of the 1% or working for them. I face the choice of starving to death to make a rental payment so I can have a place to work 90 hours a week or being forced out of business if I can't pay my tax on time. Whereas the competition are able to borrow billions from their mates, create unlimited reserves of cash and never ever have to pay it back. That really sucks! Even companies that are generating billions of dollars thanks to open source multimedia solutions like the ALSA project don't even try to give anything back to the wider community. Where are the contributions from the likes of Samsung and Google to Linux Audio and multimedia solutions? Let alone all the smaller companies that are using our software for their business products and refuse to chip in occasionally with some useful contributions.There are many corporations that are quite happy to take the work that has been done and profit from it but feel absolutely no motivation to give anything back. That sucks! -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] What KvR didn´t understand.
On Tue, January 8, 2013 1:46 am, Ove Karlsen wrote: On 1/7/2013 3:34 PM, Brett McCoy wrote: On Mon, Jan 7, 2013 at 9:25 AM, Ove Karlsen ove.karl...@paradoxuncreated.com wrote: I would like to take the oppourtunity to reply this with, that the psychiatry has become such an instritution of abuse, that bullies online have started using their phrases. lots of stuff snipped Can we just stick with discussions of Linux audio? And Personally, to idiots like these, I would like to say: www.worshipthediscusting.com is for you. From www.worshipthediscusting.com The ripest greetings from (gtc): Gay cottaging toilet-whore and general fertiliser enthusiast. This is the GTC homepage: www.worshipthediscusting.com Here we can discuss what toilets are the best, and what fertiliser gives the right sprite. Also related activities such as rolling around in maneur, claiming to be superior to the world, can be discussed here. Fantasies about being raped by big brutus in shining armour, are especially welcome, and are especially nice as a variation on our regular obession with sucking strange dicks. GTC. That is right up their alley, I think. Literally ;-) Peace Be With You. Slight contradiction here :-) There is nothing wrong with speaking your mind as it takes all sorts to make up a community but off topic discussions are generally worked out on the LAU list. Separate from that language like the above is usually reserved for IRC. We tend to be a bit less vulgar on the mailing lists even though you might find that many of the people on this list will also participate on IRC. For those that do not the crossover can be disturbing. You'll find you get a more considered discussion on the mailing lists if you try to restrain yourself from going into vulgar language to make your point. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] What KvR didn´t understand.
On Tue, January 8, 2013 3:21 am, Vytautas Jancauskas wrote: He can't be for real. Come on. That's the problem with too much Acid and Ganjah. They tend to confuse the neural pathways so what seems like rational thought processes are actually pretty abstract with large leaps being made. However it's better than extreme cocaine or crystal meth abuse because then things just become completely incoherent. Given the state of the worlds elite leadership I will take confusing ramblings of an otherwise well intentioned homophobic Acid head (even on LAD) over the piss poor performance of cocaine and alcohol soaked politicians any day. I am a little concerned at his intolerance for sexual preference. Either he is very badly brainwashed to think that homosexuality makes a person evil/stupid/inferior or he hasn't realise the immaturity of using such language as a form of attack. With his insistence that he is a godly person while also being so aggressive it seems he has a few issues to work out which could also be the cause of his obvious substance abuse. However it could be that he is just responding to his social environment. Maybe he is from a part of the world where they are intolerant towards homosexuals, believe strongly in God and are generally agressive towards anyone who does not agree with their view of the world. Not sure which part of the world that would be though. Anyone have any ideas? -- Patrick Shirkey Boost Hardware Ltd On Mon, Jan 7, 2013 at 5:48 PM, Ove Karlsen ove.karl...@paradoxuncreated.com wrote: Just get the fuck back in your chair, and clown up some code, and I am going to do whatever I want with it. Maybe ultimately you do something that resembles sanity, and I just just get in there and tighten it up a bit. I recently did that on the entire linux kernel, and made jitter-sensitive games like doom 3 run perfectly. On 5 year old hardware. Nobody knew it was possible, and many thought it was disk-reads or other things that happened, and should be there. I guess without a good man of God, are you are completely hopeless. And none of you either has done the DSP I have done. So get back to the self-torture of being you, and your suboptimal code, who no doubt gays and fertilizer enthusiasts can understand your like of. Peace Be With You. On 1/7/2013 4:46 PM, Neil C Smith wrote: For the love of insert fairy tale deity please ban obvious troll! ;) Neil C Smith Artist : Technologist : Adviser http://neilcsmith.net On 7 Jan 2013 15:41, Ove Karlsen ove.karl...@paradoxuncreated.com wrote: On 1/7/2013 4:37 PM, Nils Gey wrote: On Mon, 07 Jan 2013 14:20:16 +0100 Ove Karlsen ove.karl...@paradoxuncreated.com wrote: The Beneficient Open-Source licence: http://paradoxuncreated.com/Blog/wordpress/?p=6198 It´s still a bit work in progress, but people who generally understand open-source, should be very familier with what it expresses. Some small alternations might come, but not the general idea, of releasing as open-source, and the source staying open-source, and that it may be modified to be used alongside other licences, etc. This license is build on a lie.: to benefit humankind, in the path of God Odin does not exist but is a fairy-tale so you can't base a license his path. Better stick with the GPL. Nils Nils what you really should do is, make the Object That Moves On Its Own Licence. When you pick up a rock, it was the rock that moved itself. That is not a fairlytale. That you can tell to all the fantasyconcepts in your head, and convince yourself is right. And btw, the gay toilets away you. GTC is your friend. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing listLinux-audio-dev@lists.linuxaudio.orghttp://lists.linuxaudio.org/listinfo/linux-audio-dev ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev -- Cheshire-Puss, she began, would you tell me, please, which way I ought to go from here? That depends a good deal on where you want to get to, said the Cat. I don't care much where-- said Alice. Then it doesn't matter which way you go, said the Cat. ___ 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
Re: [LAD] What KvR didn´t understand.
On Tue, January 8, 2013 4:08 am, Ove Karlsen wrote: Even if you write an entire article against drugs, some fuckwit is going to claim you use them. Seems obvious to me that you are severely affected by prolonged substance abuse. However if you are sure that it is not substance related then I suggest you should look at getting a medical card and taking a trip down to your local green grocer. I'm sure you can find something to mellow you out there. It suits the quality of thinking that the linux audio stack and software shows. So you don't like Linux Audio? You're going to have a tough time winning over folks round here if that is your MO. Go back to retarded copypaste form obscure code, celebrate as many buttons and archaicness as possible ARDOUR. Or some here probably still think trackers are the greatest thing. Joe Hick: Look at them asciibars flowing up joe. That is some kind of technology right there. Once again you make what seems to you to be rational leaps but it ends up being just confusing. Are you actually suggesting the Ardour has an archaic interface? By archaic do you mean that is doesn't incorporate opengl 3d visuals or are you saying that you don't like the gtk toolkit? I was going to suggest that you try out Sauerbraten and Red Eclipse if you want better quality gaming experience than Quake which is IMO outdated these days. Cube engine is written in SDL and C++. The Sauerbraten community might suit your agressive nature but it appears that you would be too incoherent for those guys to put up with (and they can be brutal) so I'm not sure what would work for you now. On 1/7/2013 5:41 PM, Patrick Shirkey wrote: On Tue, January 8, 2013 3:21 am, Vytautas Jancauskas wrote: He can't be for real. Come on. That's the problem with too much Acid and Ganjah. They tend to confuse the neural pathways so what seems like rational thought processes are actually pretty abstract with large leaps being made. However it's better than extreme cocaine or crystal meth abuse because then things just become completely incoherent. Given the state of the worlds elite leadership I will take confusing ramblings of an otherwise well intentioned homophobic Acid head (even on LAD) over the piss poor performance of cocaine and alcohol soaked politicians any day. I am a little concerned at his intolerance for sexual preference. Either he is very badly brainwashed to think that homosexuality makes a person evil/stupid/inferior or he hasn't realise the immaturity of using such language as a form of attack. With his insistence that he is a godly person while also being so aggressive it seems he has a few issues to work out which could also be the cause of his obvious substance abuse. However it could be that he is just responding to his social environment. Maybe he is from a part of the world where they are intolerant towards homosexuals, believe strongly in God and are generally agressive towards anyone who does not agree with their view of the world. Not sure which part of the world that would be though. Anyone have any ideas? -- Patrick Shirkey Boost Hardware Ltd On Mon, Jan 7, 2013 at 5:48 PM, Ove Karlsen ove.karl...@paradoxuncreated.com wrote: Just get the fuck back in your chair, and clown up some code, and I am going to do whatever I want with it. Maybe ultimately you do something that resembles sanity, and I just just get in there and tighten it up a bit. I recently did that on the entire linux kernel, and made jitter-sensitive games like doom 3 run perfectly. On 5 year old hardware. Nobody knew it was possible, and many thought it was disk-reads or other things that happened, and should be there. I guess without a good man of God, are you are completely hopeless. And none of you either has done the DSP I have done. So get back to the self-torture of being you, and your suboptimal code, who no doubt gays and fertilizer enthusiasts can understand your like of. Peace Be With You. On 1/7/2013 4:46 PM, Neil C Smith wrote: For the love of insert fairy tale deity please ban obvious troll! ;) Neil C Smith Artist : Technologist : Adviser http://neilcsmith.net On 7 Jan 2013 15:41, Ove Karlsen ove.karl...@paradoxuncreated.com wrote: On 1/7/2013 4:37 PM, Nils Gey wrote: On Mon, 07 Jan 2013 14:20:16 +0100 Ove Karlsen ove.karl...@paradoxuncreated.com wrote: The Beneficient Open-Source licence: http://paradoxuncreated.com/Blog/wordpress/?p=6198 It´s still a bit work in progress, but people who generally understand open-source, should be very familier with what it expresses. Some small alternations might come, but not the general idea, of releasing as open-source, and the source staying open-source, and that it may be modified to be used alongside other licences, etc. This license is build on a lie.: to benefit humankind, in the path of God Odin does not exist but is a fairy-tale so you can't base
Re: [LAD] What KvR didn´t understand.
On Tue, January 8, 2013 5:41 am, Florian Paul Schmidt wrote: On 01/07/2013 06:24 PM, Nils Gey wrote: On Mon, 07 Jan 2013 18:15:13 +0100 Ove Karlsen ove.karl...@paradoxuncreated.com wrote: You are hereby banned from heaven. You don't have the authority to ban anyone from heaven. Only I have the authority because I am the only living descendent from the children of Jesus and Mohammed when they met on the holy toilet. I am honoured that the most WTF-worthy troll-sh*t-storm I ever personally witnessed on LAD is a direct consequence of my little innocent announcement :D Have fun flaming, Flo /me grabs another bag of popcorn He went off list and in the words of Doctor Evil it got weird, didn't it? http://amadcity.files.wordpress.com/2012/08/it-got-weird.jpg -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Mon, December 10, 2012 10:42 pm, Bill Gribble wrote: I have done some proof of concept tests with pyopencl that look interesting. There are practical problems: you add a whole other domain to process in, in addition to Python-world and Jack-world. You have deployment issues with the OpenCL libs for different GPU vendors. The wide SIMD architecture of GPUs is really only helpful for certain audio ops like convolution, or very wide banks of identical processing. And if you are using the card for graphics, there may be unpredictable interactions. We have several headless machines running GPU's with thousands of processing units available. Much more power than the first Lord of the Rings movie was made with. Still worth exploring though, and a cl~ processor for my system is definitely on the todo list. We are exploring the possibilities here too. Essentially a library that allows sending specific operations across a netjack cluster for realtime multimedia processing. Thanks, Bill Gribble On Dec 10, 2012, at 6:19, Patrick Shirkey pshir...@boosthardware.com wrote: On Mon, December 10, 2012 9:06 am, Bill Gribble wrote: Patrick, interesting stuff! I am about to push an early version of my current project to github -- python and clutter implementing a puredata knockoff (with python data types and evaluator). I've found it to be a good combo so far, using multiprocessing to separate engine, UI, and DSP (in C extension). That is my experience with the combination too. I have also found it works nicely as an addition to a gtk3 interface using the embed() option. That gives a gtk3 wrapper with direct cairo support while allowing easy access to clutter, opengl and the advanced gesture and animation support. It's a pretty powerful combo. One thing I am still working on is getting direct access to the GPU for additional processing grunt. Thanks, Bill Gribble On Dec 9, 2012, at 16:20, Patrick Shirkey pshir...@boosthardware.com wrote: On Mon, December 10, 2012 3:37 am, Louigi Verona wrote: Hey Patrick! In what way would you say this is different from JACK Keyboard? First it uses alsa midi through the alsaseq library. Second it is written in python3. Third it uses the Clutter opengl UI toolkit. I'm not sure if jack keyboard supports 128 midi keys. CMKeyboard is not intended to replace jack keyboard. It's about getting some traction using Python3 and Clutter. Clutter and Python are two under utilised options in LAD. Not sure why Python is not so popular considering how many professional and highly successful AV projects have been built with it but Clutter seems to have been off the radar for a while. Maybe now that the new touch interfaces are arriving in the market this year we will see a pick up in Clutter projects for LAD applications. On Dec 9, 2012 7:28 PM, Patrick Shirkey pshir...@boosthardware.com wrote: Announcing CMKeyboard - Clutter MIDI Keyboard http://djcj.org/cmkeyboard CMKeyboard is a 128 note ALSA MIDI virtual piano keyboard spanning from C-1 to G9 written in python3 and taking advantage of the latest Clutter (1.12.2) features to enable scrolling and opengl goodness. It is a stand alone program which can also be embedded into other python3 applications as a class library. It uses code from the very handy pyclutter-widgets project for the rounded rectangles of the key buttons. The code demonstrates use of Clutter.ScrollActor(), GtkClutter.Embed(), layering of multiple clutter actors, handling of events including: button-press-event key-press-event. Suggestions for features and improvements welcome. Enjoy! -- 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-user mailing list linux-audio-u...@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-user mailing list linux-audio-u...@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-user -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Tue, December 11, 2012 3:33 am, David Robillard wrote: On Mon, 2012-12-10 at 11:12 -0500, Paul Davis wrote: On Mon, Dec 10, 2012 at 10:56 AM, Patrick Shirkey pshir...@boosthardware.com wrote: We have several headless machines running GPU's with thousands of processing units available. Much more power than the first Lord of the Rings movie was made with. Still worth exploring though, and a cl~ processor for my system is definitely on the todo list. We are exploring the possibilities here too. Essentially a library that allows sending specific operations across a netjack cluster for realtime multimedia processing. you might want to check the latency before you get too far into plans like this. i've heard that it is improving, but still not really what one would expect of a realtime FX processor. Indeed. Crazy throughput, but transferring to and from the GPU kills you. Worth investigating anyway since many-core is probably going to stick around and become faster, but I doubt current GPUs can achieve reasonable real-time audio latency. This is the part we are working on. It requires building the software and then discussing the issues with the driver developers directly. Takes time and effort in more ways than one. Plus there are certain forces actively working against us to put as many barriers in the way as possible. I think the programmable GPUs on recent Intel chips (Ivy Bridge) is an interesting development; though much less powerful and far less cores, they have full memory bandwidth (the other thing that kills you), and presumably minimal latency since it's on-die. Adding 8 or so cores may not be in the same realm as adding hundreds, but for many things the latency and memory bandwidth dominates anyway so a billion cores on a GPU would still be slower. Anything memory bound is much slower even on the best GPUs. I'll happily take 8 extra cores on the CPU... AMD Fusion chips are CPU/GPU combos so you get the best of both in that regard. The next gen HSA platform promises to be even more powerful but AMD will have to survive long enough for that promise to be delivered. They have made some recent progress with opencl support for Linux so that has been well received. Unfortunately they're not programmable on Linux yet, only on Windows. I have been assured that the brand new NUC platform from Intel is fully Linux compatible with opengl/cl support too. What specific issues are you seeing? A complete joke if they're targeting scientific GPGPU, and useless for LAD too. Intel seriously needs to get on this and fix their drivers... Compared to AMD, Intel are actually making a lot of headway with their Linux drivers. At least they actually release the specs these days and have a full department for Linux development. AMD are having real trouble getting their heads around the concept of open source *and* multimedia. My dealings with Intel so far suggest they are light years ahead in terms of understanding the potential. Compared to AMD it's almost night and day. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Tue, December 11, 2012 7:28 am, David Robillard wrote: On Tue, 2012-12-11 at 05:40 +1100, Patrick Shirkey wrote: On Tue, December 11, 2012 3:33 am, David Robillard wrote: [...] Unfortunately they're not programmable on Linux yet, only on Windows. I have been assured that the brand new NUC platform from Intel is fully Linux compatible with opengl/cl support too. What specific issues are you seeing? Last I checked, which was quite recently, they were literally not programmable on Linux whatsoever. The issue is it's completely unsupported on Linux and does not work at all. (OpenCL on the normal CPU cores works, mind you, but is embarrassingly slow compared normal threaded code, so that's useless) I was told the following regarding the NUC platform and acceleration (The NUC's don't have a GPU): The Kernel driver supports IVB accelerated 3D. You will need, in addition to the Kernel driver, the Mesa component (which is the open source OpenGL implementation).The latest release of Mesa also has full IVB support and had for sometime now. I have been waiting to get hold of one, as they are only a few hundred dollars, to find out exactly how far they can be pushed. They are now on the market for the xmas season. They look like they will be very useful for low energy footprint, high performance multimedia clusters. Also for networked display installations. Solar powered netjack clusters... A complete joke if they're targeting scientific GPGPU, and useless for LAD too. Intel seriously needs to get on this and fix their drivers... Compared to AMD, Intel are actually making a lot of headway with their Linux drivers. At least they actually release the specs these days and have a full department for Linux development. AMD are having real trouble getting their heads around the concept of open source *and* multimedia. My dealings with Intel so far suggest they are light years ahead in terms of understanding the potential. Compared to AMD it's almost night and day. Unfortunately Intel is light years ahead of AMD in most things these days. Though, if AMD has CPUs with on-die programmable GPUs in Linux, I for one would be quite a bit more interested... The AMD Fusion chips are GPU on die and they have recently released a large chunk of opencl tools. I haven't had time over the past few months to look into exactly how much access is now available. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] opencl [was Re: [LAU] ANN: CMKeyboard]
On Tue, December 11, 2012 3:32 am, Bill Gribble wrote: On Tue, 2012-12-11 at 02:56 +1100, Patrick Shirkey wrote: On Mon, December 10, 2012 10:42 pm, Bill Gribble wrote: We have several headless machines running GPU's with thousands of processing units available. Much more power than the first Lord of the Rings movie was made with. Good stuff to have available! Even on a normal laptop with external GPU chipset and the builtin Intel one too there's a pretty powerful idle processor. That's why I started getting interested. Also, I penciled out a hardware setup that would allow a laptop to add external PCI graphics cards for this purpose, seems like a great choice for convolution reverbs, long FIR filters for linear-phase EQ, etc. It's also handy for rendering video graphics and ffmpeg/libavcodec has some support for accelerated processing too. Blender and Ardour make an incredibly powerful combination but the complete toolset is just incredible with a tightly honed cluster. I mention interactions because there are a few commercial GPU-accelerated audio plugins for Windows (convolution reverb was all I could find, can't remember the name offhand), and I spent some time scraping forums at the manufacturer, gearslutz, etc for information about real-world performance. The reports were that the latency for executing OpenCL kernels was pretty unpredictable, and seemed to be related to resource allocation by the desktop OS. Not an issue in your case, nor in any case where you have a dedicated chip (or render farm) for your own purposes. We are attempting to push the limits of the software and hardware as much as possible. One of my priorities is workflow integration. Figuring out where the holes in the system are and looking at ways to seal them to increase usability. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] ANN: CMKeyboard
Announcing CMKeyboard - Clutter MIDI Keyboard http://djcj.org/cmkeyboard CMKeyboard is a 128 note ALSA MIDI virtual piano keyboard spanning from C-1 to G9 written in python3 and taking advantage of the latest Clutter (1.12.2) features to enable scrolling and opengl goodness. It is a stand alone program which can also be embedded into other python3 applications as a class library. It uses code from the very handy pyclutter-widgets project for the rounded rectangles of the key buttons. The code demonstrates use of Clutter.ScrollActor(), GtkClutter.Embed(), layering of multiple clutter actors, handling of events including: button-press-event key-press-event. Suggestions for features and improvements welcome. Enjoy! -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] ANN: CMKeyboard
On Mon, December 10, 2012 3:37 am, Louigi Verona wrote: Hey Patrick! In what way would you say this is different from JACK Keyboard? First it uses alsa midi through the alsaseq library. Second it is written in python3. Third it uses the Clutter opengl UI toolkit. I'm not sure if jack keyboard supports 128 midi keys. CMKeyboard is not intended to replace jack keyboard. It's about getting some traction using Python3 and Clutter. Clutter and Python are two under utilised options in LAD. Not sure why Python is not so popular considering how many professional and highly successful AV projects have been built with it but Clutter seems to have been off the radar for a while. Maybe now that the new touch interfaces are arriving in the market this year we will see a pick up in Clutter projects for LAD applications. On Dec 9, 2012 7:28 PM, Patrick Shirkey pshir...@boosthardware.com wrote: Announcing CMKeyboard - Clutter MIDI Keyboard http://djcj.org/cmkeyboard CMKeyboard is a 128 note ALSA MIDI virtual piano keyboard spanning from C-1 to G9 written in python3 and taking advantage of the latest Clutter (1.12.2) features to enable scrolling and opengl goodness. It is a stand alone program which can also be embedded into other python3 applications as a class library. It uses code from the very handy pyclutter-widgets project for the rounded rectangles of the key buttons. The code demonstrates use of Clutter.ScrollActor(), GtkClutter.Embed(), layering of multiple clutter actors, handling of events including: button-press-event key-press-event. Suggestions for features and improvements welcome. Enjoy! -- 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
[LAD] E-MU 0404 USB [was :Re: [LAU] Linux Audio 2012: Is Linux Audio moving forward?]
On Fri, October 12, 2012 12:31 am, Louigi Verona wrote: Speaking of hardware drivers, long time ago I wrote this article on E-MU 0404 USB: http://www.louigiverona.ru/?page=projectss=writingst=linuxa=linux_emu0404usb For a long time it was my mostly read article. Some people theorized that it is possible to make the soundcard working, but my tests have concluded that it is surely impossible without voodoo spells. Is there any system solution to these kind of things, when the specs are available, but nobody cares? In this situation you will make progress by joining the alsa-devel mailing list and offering to Q/A, debug and report back on results of any code updates. If you are prepared to put in some effort it will not take too long to make some real progress. For driver development on new alsa drivers you have to be prepared to be actively involved. You can't expect the alsa developers to make updates if no one is giving them any useful feedback. Otherwise you could offer to send the device to someone on the list and have them work on it. But that takes out all the fun of the Q/A process and you'll probably get better results if you have two people debugging and testing than one. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Linux Audio 2012: Is Linux Audio moving forward?
On Thu, October 11, 2012 5:41 am, Dan MacDonald wrote: Patrick wrote: Looking at the recent trade shows it seems that Linux/Unix is the already the hardware standard. I didn't spot hardware running on Apple or M$ OS's but plenty of Linux and Unix platforms. Which trade show was this? Integrate is the biggest A/V trade show in Australia. It's just a baby compared to US or EU offerings though. I'm unaware of any hardware vendors advertising or even officially supporting Linux other than RME kinda but their support seems little more than half-hearted as they apparently don't provide any support for their drivers which they say on their website are 3rd party so did they even have any involvement in them at all? Focusrite provide specs but no Linux drivers or support so I wouldn't count them either. Just walking around you can see who is using Unix/Linux and who is not. Granted most of it is embedded or SoC but they are definitely not Apple or Mac OS's on the clear majority of the hardware solutions. Unfortunately for us in the proprietary world it's not cool to talk about where you get your firmware/software from so no one is promoting that information. When it comes to desktop solutions no one is representing Linux at the trade shows here. Afaik noone is doing anything explicit for Linux Multimedia solutions at any of the US or EU trade shows either. Given that there are several companies on these lists who do go to the trade shows it seems that we are all missing a big opportunity for promotion of the general platform by not capitalising on the We heart Linux bandwagon. I know its not audio related but even HP who's support for Linux is arguably better or at least on a par with their support for the other two OS still don't advertise or claim to officially support Linux - even though they do. Sad state of affairs - even now in 2012 when we can all safely say Linux isn't going away the big corps still like to pretend it doesn't exist. Valve just announced that the Linux port for Steam will go live with 15 titles. Intel, AMD and ARM all promote Linux heavily. The entire top level of the movie industry runs on Linux. Harrison is building Linux Hardware Solutions. RME provides Linux support or standards compliant devices. What is missing is a concerted effort to advertise and promote the advances that have been made. We can't rely on the magazine and mainstream news media publishers to do it for us as they are clearly not interested. So we have to do it ourselves which either means paying the publishers for space or blanketing the web with information. Given that we are unlikely to crowd fund advertising the latter is more viable. Considering that we have several thousand LAU people who also just happen to be handy with a computer and the internet that actually works in our favour. Marketing companies spend millions of client dollars on SEO and manage to get a lot done with just a few dedicated people. We have thousands of users and each one of us can build a website or post links in forums and social media to the landing pages that we want to promote. Our sites all link up to each other anyway so it just needs some effort from people around here to spread the links and evangelise the platform. Having some killer content won't go amiss either. Perhaps the professional companies round here have some AV content that they would like to share more widely for promotional purposes? We are actually looking for some content we can turn into a show reel. So if you know of anything that would be suitable please let us know. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Linux Audio 2012: Is Linux Audio moving forward?
On Thu, October 11, 2012 6:52 am, Louigi Verona wrote: @Folderol: While it is nice to have lots of different apps, plugins, whatever, I think you find most musicians quickly settle on a very small range which they get to know extremely well. This is true. However, before you settle, you do need to have a choice. And there is very little right now. @Dan: He made a number of valid points but I have to agree it was a bit overly negative. Linux audio has come a long way in the last few years- if still trailing some way behind commercial offerings in some areas but its unrealistic to expect otherwise when the big boys have large teams working full time on development plus some of the apps (Cubase etc.) effectively pre-date Linux back to the 80's. You point out the reason why things are as they are. I did not speak about the reasons, I tried to capture how I see the state of things, independent of the reasons. Noting that Linux has come a long way and that we cannot expect hobbyists to do as well as professionals has nothing to do with a completely independent statement that Linux has few plugins compared not even to Windows but to some musicians' needs. ;) I think sometimes it is useful to take such perhaps a slightly negative look. As long as it is not desperate, this kind of reflection can be useful to always be realistic about one's achievements or about state of things. Also, I have a hidden hope that someone disproves my view and shows that in reality everything is not so bad ;) The problem with that approach is that it tends to feed the negative attitude towards Linux and that is exactly what the competition want. So by trashing the platform to gather informed responses it can do more harm than good from a marketing and promotional angle. However that method works very well for Fox and The Register so it's definitely a valid approach. After years of trash talk or being ignored what we really need is a dedicated effort to bigging up all the things that can be done. Which reminds me, if anyone has any tutorials they want to share on the quicktoots website please send them my way. We get about 500 views a month on that site at the moment and as it has been online for almost 10 years that means almost 50,000 people have viewed tutorials on that site. The toots don't have to be recent or cutting edge. Just useful and informative :-) BTW, for the professional companies out there that is 50,000 very attractive sales prospects that you could have been marketing to for the past 10 years. So if you are a company and want to increase your sales potential it makes sense to be providing professional tutorials for inclusion on the quicktoots site on a regular basis. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Linux Audio 2012: Is Linux Audio moving forward?
On Thu, October 11, 2012 7:25 am, Louigi Verona wrote: @Patrick: The problem with that approach is that it tends to feed the negative attitude towards Linux and that is exactly what the competition want. There is no competition, Patrick. Windows Audio does not compete with Linux Audio. Only if in our minds. And thus they do not want anything. There are plenty of competitors to Linux Audio as a platform. AVID is the most obvious competitor. There is no Windows Audio community, there is a Linux Audio community. We try to compete with them. They do not compete with us. Look at things from a professional business point of view and try again please. I'm not talking about Linux Multimedia for amateur users or even necessarily for artists/producers. I'm talking about businesses that use Linux as their revenue generating platform. Also, talking positive will not solve things. I see little value in promoting Linux Audio, for instance, for my electronic musician friends - I have to honestly tell them that making the kind of music they do is not easy on Linux. What kind of music do they make that is so difficult to do on Linux? Don't you mean that because insert favorite application/plugin is not ported they will have to learn how to do something differently and that is too much to ask? If that is the case then they are probably not a good fit for a Linux desktop experience but I wonder how they managed to get anything done in the first place if they are averse to learning. I like it and I am doing it, but I would not advertise Linux Audio as comparable to Windows Audio since it is simply not true. And it's a good thing too. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Linux Audio 2012: Is Linux Audio moving forward?
On Thu, October 11, 2012 10:00 am, Jörn Nettingsmeier wrote: On 10/10/2012 11:00 PM, Patrick Shirkey wrote: On Thu, October 11, 2012 7:25 am, Louigi Verona wrote: @Patrick: The problem with that approach is that it tends to feed the negative attitude towards Linux and that is exactly what the competition want. There is no competition, Patrick. Windows Audio does not compete with Linux Audio. Only if in our minds. And thus they do not want anything. There are plenty of competitors to Linux Audio as a platform. AVID is the most obvious competitor. that's a bit like saying NASA is competing with the RC model helicopter community. i'm pretty sure the whole professional *non-embedded* linux audio market is a fraction of the size of AVID's _marketing_ budget. That is simply because the majority of the businesses are not supporting the Linux platform. It has nothing to do with the viability of Linux audio as a platform for serious multimedia production. It's more like comparing NASA with CNSA. One is a bloated organisation that is on it;s last legs that relies on marketing and propaganda to sell it's agenda and the other is a dynamic and productive organisation that is quickly achieving significant results surpassing the technological achievements of the other with very little reliance on marketing or propaganda. now under the hood, things look quite different, but that doesn't have much impact on the public opinion towards or perception of linux. There is no Windows Audio community, there is a Linux Audio community. We try to compete with them. They do not compete with us. Look at things from a professional business point of view and try again please. I'm not talking about Linux Multimedia for amateur users or even necessarily for artists/producers. I'm talking about businesses that use Linux as their revenue generating platform. i'm one such business, and despite my healthy illusions of grandeur i don't consider myself part of a relevant market for any major equipment or software manufacturer. besides the obvious technical benefits of using linux (for my particular kind of workflow), the main advantage to me is to be able to _ignore_ the rat race of the mainstream pro audio software market. Don't you mean that because insert favorite application/plugin is not ported they will have to learn how to do something differently and that is too much to ask? that's not how marketing works, and that's not how the market works. the goal is to get kids to buy dsp cards with emulations of old UREIs that are great for snares and female vocals, and another emulation of an old fairchild which is great for male voices and kick drums, and the way to do it is to get fat old mixing gurus to advertise that kind of gear on youtube. the linux community doesn't have those dsp cards to sell, our plugins don't have the kind of bling, and people who give their stuff away are less inclined to bullshit kids out of their money. we have a few limiters with a bunch of parameters that give useful results on all kinds of program material, all they lack is the instant rocknroll credibility thing of a fat bearded guy with a metallica t-shirt at a 96-channel ssl who compares them to his obsolete analog treasures and praises them to high heaven. hence, in my view, the absence of a market like this is a good thing. We can certainly find fat bearded guys with black T-Shirts and a lot of equipment if anyone feels like making those kind of ads. the only time it hurts is when i cannot get hardware support for gear that i need. but these days, i can get linux drivers for everything from 2 to 128 channels of i/o (more if i'm prepared to gang cards), so what's the problem? It's not a problem for you or me personally but for business people who are seeking to make a living out of the Linux Audio and multimedia platform getting access to a larger customer base of people who don't have the supported cards is a good thing. intel and amd thankfully make dsp cards that will also deal with my email and run my browser (word processing on a sharc, anyone?), and they are well-supported by linux :) I like it and I am doing it, but I would not advertise Linux Audio as comparable to Windows Audio since it is simply not true. And it's a good thing too. here i whole-heartedly agree! -- Jörn Nettingsmeier Lortzingstr. 11, 45128 Essen, Tel. +49 177 7937487 Meister für Veranstaltungstechnik (Bühne/Studio) Tonmeister VDT http://stackingdwarves.net ___ 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
Re: [LAD] Kontakt sampler format (and others like EXS24)
On Sat, September 1, 2012 3:12 am, Harry van Haaren wrote: On Fri, Aug 31, 2012 at 4:27 PM, Paul Davis p...@linuxaudiosystems.comwrote: A lot of people (even on this list) don't understand the extent to which *supporting* a piece of software is often a far bigger cost than the initial development, and providing support for a platform with very few users is an issue for companies who want their customer service reputation to be very good (as NI does). It doesn't work for companies like this to just release something into the wild and forget about it. That's a fair point. And also one I'm not in a place to make : I'm not currently doing any software support. Still I do feel that if there could be an interaction whereby the linux audio community gets enough info to use Kontact samples natively in JACK that would be awesome. With risk of talking about what I'm not an expert in: I could see some kind of binary .so distributed by NI that houses the Kontact internals, with a header file describing how to use it. If this could be adapted into the shape of a LinuxSampler engine, then win-win right? -NI don't have to do support: the only customer for thier .so is a developer, so support isn't even the right word. -LinuxSampler is an established project: why repeat all that has already been done? -Kontact usage goes up (strengthens brand name.. etc etc) and I'll buy samples from NI. Again intrested on views... also from the Linux sampler guys if such an endeavor would even be possible given that the politics work out. -Harry I think Paul has already framed this. They are not comfortable putting it out in the wild unless they are sure that their quality standards will be met. In that case they will need to have a support agreement with the LS guys and that means Christian et al will have to work, which means unless they can get NI to pay them for their time they either have to work for free or make enough money from the associated projects that gain by having NI support. Given that almost no one in this mailing list actually spends significant amounts of money on Linux Audio Software that means they have to get income from a much larger userbase and until we have definitive proof that userbase is going to contribute income to the project the only thing driving it forward is self motivation. So, if we want projects like this to succeed we as a community have to be prepared to make the effort to educate the wider market. Which means everyone contributing to the global marketing effort... So, get our your blogs, your tweet decks, your facebooks, your pinterests, your myspace and your diggs, start writing keyword rich content and linking it back to our community landing pages, flood the forums with links, and even gasp *pay* real money for advertising in real physical media like magazines and trade journals and then let's see how big our global userbase really is. As it stands there is a push towards NAMM in January 2013 but compared to the rest of the noise out there it will be easily lost in the crowd if we don't put in the time to capitalise on it. Those people who are in the States and have some spare time and resources might want to consider getting involved in a grassroots education campaign for the NAMM conference. There are several companies that are going to be there this year so having a side event or even pooling resources to make a theme might raise some eyebrows in a good way. One thing we have going for us is that the products we make are definitely high end so that is a good place to start if we want to create a marketing theme and educational campaign based around it. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Promoting Linux Audio Businesses and Institutions
Hi, If you would like to promote your Linux Audio Business or educational facilities to a wider audience who are actively looking for information about Linux Audio there is some banner real estate on http://linux-audio.com which is available for a limited time free of charge to early birds. Please contact me directly and I will give you more details on the process. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
[LAD] Linux Audio Companies
Hi, If you have a company or know of someone who has a company that uses Linux Audio tools/software to enable productivity can you please send me the following info: Company Name Website Location Business Expertise -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] [LAU] Linux Audio Companies
On Mon, July 23, 2012 2:48 pm, Nils wrote: On Mon, 23 Jul 2012 14:45:13 +0200 (CEST) Patrick Shirkey pshir...@boosthardware.com wrote: Hi, If you have a company or know of someone who has a company that uses Linux Audio tools/software to enable productivity can you please send me the following info: Company Name Website Location Business Expertise Yes, here http://www.youtube.com/watch?v=anwy2MPT5RE Cos, your being so productive as the internet faux fascist police agency Step up or if you can't handle the pace get out of the way! -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] AMS LV2 plugins: Version 0.0.6
On Sun, 2012-03-11 at 10:01 +, Aurélien Leblond wrote: Hello everyone, During this jolly holidays, I worked a bit on the AMS LV2 plugins. The version 0.0.6 can be downloaded here: http://sourceforge.net/projects/avwlv2/files/avw.lv2.0.0.6.tar.gz/download Ack! Why the heck do these plugins have URIs at http://lv2plug.in?! Don't give things URIs at domains you don't control without at least permission! -dr Hi David, Sorry about that, I simply started to work from other examples and never changed the URIs as I didn't think it matter in any way! Well, it doesn't really matter depending on how you look at it, but in general it's inappropriate to claim big chunks of namespace in other people's domains. I thought this was obvious but I suppose the examples need to state it explicitly. The main practical thing you lose is the convenience of people being able to plug those URIs into a browser and actually getting to information. That said, we can perhaps establish chunks of namespace at lv2plug.in if people want them, but you at least have to ask :P Maybe we should use PURLs or set up a similar simple redirect service at lv2plug.in for people who don't have a long-term stable namespace to use... Sounds like a useful service. You could even make some money out of it by charging corporate users for the privilege... If I do bn't control any domains, what can I use as URI? You control http://avwlv2.sourceforge.net/, calf uses its sourceforge URI. -dr -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Tutorial for programming with JACK
I want to learn how to program with JACK. I found this tutorial: http://dis-dot-dat.net/index.cgi?item=/jacktuts/starting/ linked from this page ( http://jackaudio.org/documentation ). I noticed that the tutorial has some broken links. Is this still a good resource to learn from? Or are there any better ones out there? Any suggestions will be much appreciated. Depends what you want to do. Might be just as useful to look at the example applications included in the repo or any of the other jack apps. The source is very well annotated too. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Tutorial for programming with JACK
Depends what you want to do. Might be just as useful to look at the example applications included in the repo or any of the other jack apps. The source is very well annotated too. I will definitely be looking at the example applications. I want to eventually understand how DAW applications like Ardour and Qtractor in particular are written, but the source code of those apps are quite intimidating to me at the moment. If there is anything else I can do to aid in my learning, that would be great. jackeq is pretty simple in the way it handles jack routing but it has multiple ports so it might be useful for you to read that codebase. It is also a gtk2 application so you can get an overview of one way to handle the gui aspect. http://djcj.org/jackeq Hydrogen also has a fairly easy to parse implementation and is pretty modular. That would give you an overview of a qt application. But in the end you will learn best by just reading those code for Qtractor and Ardour. Just choose a section you want to learn about and trace it to the start point then read from there. It will take a couple of days/weeks to get your head around it but eventually it will just click into place :-) -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] bleeding edge html5 has interesting Audio APIs
On Tue, 2011-11-22 at 00:41 +0300, Louigi Verona wrote: Hey guys! I have worked several years as a web developer and continue to create personal projects actively. What can I say - the web obviously has lots to offer. However, the client-side has more promises than actual accomplishments, especially when it comes to cross-browser things. Want it or not, even jQuery has problems, especially on (you guessed it) IE. The amount of hacks one needs to put it to make even normal html look the same in FF and IE is enormous. Experienced html guys might not notice how much hacks they automatically put into the code. If you choose to care about IE, life is indeed going to be miserable. I certainly don't ;) Not to mention the memory problem. Browsers simply cannot handle as much memory as a desktop app can and you never know if settings of the visitor of your web app will allow him to not have his browser crash. As for graphics, each solution available today has loads of issues and nothing I've seen is satisfactory. Google stuff is interesting, but how lasting it will be - nobody knows. I would agree that the web has potential. I would agree that Java failed as a dream of an ultimate platform for all. But I would not agree that the web is there already today, nor that it is close. In terms of actual interaction it is very, very far away from what even a Java tool like Processing can offer, not to mention all of Java. There seems to be the impression that I, or anyone, is arguing that absolutely every UI ever is best implemented in the browser. Of course, not, that's silly. But most audio control UIs are quite simple. All we need is a couple of sliders and knobs and such. It's quite straight forward and perfectly appropriate. Transport controls, faders, knobs, XY pads, step sequencing, toggles, all that kind of stuff. Having remote controls and plugin UIs and such in the browser would be awesome, and it's not anywhere near the realm of things too large to be feasible, or too complicated to be portable (even to that atrocity you mentioned). Does html5 support JACK yet? That will be nice. If you need very high performance realtime visualization or whatever, sure, dont use the browser. Duh. With html5 support for opengl this is actually decent on new browsers. Put differently: nobody is going to be rewriting the main Ardour UI in Javascript any time soon - but it would make a great control surface. -dr ___ 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
Re: [LAD] bleeding edge html5 has interesting Audio APIs
On Sun, 2011-11-20 at 06:04 -0500, hollun...@lavabit.com wrote: [...] I realize this question might be provokative, but I've never seen this comparison before and am genuinely interested in your opinion. Both java and browser/JS are cross platform. Both are available on almost every device out there. Why is browser/JS the way to go? Because that is *actually* true of browser/JS, and not for Java. * Most Windows computers do not have Java. * Java is officially deprecated on Mac OS X. * Java will never, ever be available by default on any Microsoft platform * Java is not included in the default installation of the overwhelming majority of free software operating systems * Neither the most popular tablet nor the most popular smart phone (the iPad and iPhone, respectively) have Java at all. * Java requires software installation of some variety (unless you're seriously going to suggest using Java applets in 2011 with a straight face...) * Java recently has acquired a lot of legal questions making it not exactly the wisest investment for new technology. * There are many cutting edge modern browser implementations, and activity here is moving at an astonishing pace. Java is a dinosaur. This is not the 90's. The client side Java dream failed. Regardless, if I may take the liberty of speaking for this community, making people use Java for something is a sure-fire way of ensuring they don't use it. The reasons why don't really matter. The browser Just Works. Java is a PITA. Except that while java 6 stayed stable for several years it allowed people who just wanted to get things done and not have to worry about the constant hassle of dependencies and upgrades to work on improving the features of their software. However now that java 6 has been deprecated and Oracle is being so painful many people will move away from java. That still won't solve the problem of maintaining stability. It is nice to be able to easily compile and install software that has been recently updated on older machines that run perfectly well for everything else that they have been painstakingly setup to handle without having to completely rebuild the OS every 6 months to keep up with all the changes. Even installing jack on older systems can be a royal pita let alone all the older apps that are no longer working on newer versions of various systems due to the devs not keeping up with the latest advancements. Stability of a functioning build environment does have it's merits. -- Patrick Shirkey Boost Hardware Ltd ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] platform choices, jack for sequencing?
Thanks everyone for all the help on my architecture questions. It seems like a lot of the best practise functionality has tools/components for it already in Jack. I *was* planning on using rtaudio in order to be cross platform, but if it's a lot easier to get things done in Jack, i could live with being limited to linux and OS X. Jack2 runs on windows too. Just that it hasn't seen as much adoption as most of us round here refuse to work with MS tech unless paid a lot of money to do so. Some of us just refuse outright. But Stephan and his team have put in a lot of effort to make it work on MS platforms. Just wondered if I could poll opinions, for a real time step sequencer meant to do super tight timing and by syncable with other apps, is Jack going to be a lot easier to work with? Should I just lay into the jack tutorials? It doesn't take long to get a jack app up and running. Its the front end that will consume the vast majority of your time. And is it straightforward to use the perry cook stk in a jack app? https://ccrma.stanford.edu/software/stk/usage.html Several options can be supplied to the configure script to customize the build behavior: --disable-realtime to only compile generic non-realtime classes --enable-debug to enable various debug output --with-alsa to choose native ALSA API support (default, linux only) --with-oss to choose native OSS audio API support (linux only, no native OSS MIDI support) --with-jack to choose native JACK API support (linux and Macintosh OS-X) --with-core to choose Core Audio API support (Macintosh OS-X) thanks everyone iain ___ 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
[LAD] Realtime Audio on Android
Hi, I'm working on a cross platform mobile OS media player and doing some research into Realtime audio playback on Android at the moment. It seems there is a fairly small amount of info online and a lot less fully fledged code examples than available for the iPhone platform. For example I have already implemented my demo app in objective-C but it looks like it is going to be significantly more effort to do the same for Android. I have found a couple of interesting posts and articles about the current state things. Maybe people round here would like to comment on the situation? Here's what I have found so far: 1: There are three main API's - mediaPlayer, SoundPool, AutdioTrack with openSL ES in the works for release sometime in the near future. 2: All of the Android API's do not provide true low latency support and have varying bugs that need to be worked around with native code. The pd team have made some progress on the workarounds based on jack style callback wrapper classes. 3: There is no standard library for decoding audio file formats at the lower level. Although several options exist including native java implementations for mp3 (JLayer), and custom code from developers like Ivan Memruk from mindtherobot.com 4: There is no native midi or OSC support and it looks like there is no LV2 or ladspa port at this point either. There are very few open source demo apps available which provide a complete solution for media playback and recording at low latency. It seems that the pd implementation is the only one. Overview: http://www.wiseandroid.com/post/2010/07/13/Intro-to-the-three-Android-Audio-APIs.aspx http://mindtherobot.com/blog/555/android-audio-problems-hidden-limitations-and-o http://mindtherobot.com/blog/555/android-audio-problems-hidden-limitations-and-opensl-es/pensl-es/ http://mindtherobot.com/blog/555/android-audio-problems-hidden-limitations-and-opensl-es/ Sample code: http://mobiledeviceprogramming.blogspot.com/2010/10/fun-with-android-audiotrack.html http://mindtherobot.com/blog/580/android-audio-play-a-wav-file-on-an-audiotrack/ http://mindtherobot.com/blog/624/android-audio-play-an-mp3-file-on-an-audiotrack/ http://blog.pocketjourney.com/2008/04/04/tutorial-custom-media-streaming-for-androids-mediaplayer/ Workarounds / Middleware: http://gitorious.org/pdlib http://www.typhon4android.org/ Cheers. -- Patrick Shirkey Boost Hardware Ltd. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
Re: [LAD] Good Mixer Library
On 04/01/2011 04:03 PM, Devin Anderson wrote: On Thu, Mar 31, 2011 at 9:32 PM, Patrick Shirkey pshir...@boosthardware.com wrote: I am just not sure that I can get away with discussing the topic in the open due to the possibility of being struck down by the almighty power of on high or bringing disrespect to those who are believers in the sacrosanct nature of the reigning King of Kings. I'm confused. Are you trolling about not trolling? Not at all! I am genuinely concerned about the possibility of offending the fervant believers in the righteous power of the App that shall remain nameless and the sanctity of that hallowed institution leading the way for us mere mortals in the eternal quest for realtime performance and enlightenment of the dance massive. It is clear that discussion of the Taboo could lead to a fatal turn of events that might leave us completely at the mercy of Government corruption and ineptitude while we endeavour to shield ourselves from the ensuing radioactive fallout of a massive nuclear event caused by the shifting techtonic plates due to the impact of global warming from the excessive consumption of fossil fuels brought about by the need to provide a rock solid environment for Audio posers and Professionals alike to achieve their goals of world domination while at the same time enjoying all the benefits of a successful career in the music industry and the wealth, status and success that goes with selling out to the highest bidder to provide corporate sponsored entertainment of the mass market driving the entertainment market into fits of passion at the mere sound of the latest autotuned sample while overlayed with the darkest philosophical perspective due to the Mass Media Industrial Military complexes desire to manipulate our thoughts with their pervasive agenda of death and destruction on a global scale in order to confuse into ignoring the depth of corruption and negligence inherent to the self fulfilling system of Political and Corporate greed enhanced by the merger of the fiat currency system with multimedia devices running competing mobile operating systems to ensure vendor lock in while we give away our rights in order to make sure we can enhance the facial recognition technology of the Elite Societies that require total dominance of the international global market for divine intervention in the nationalised institutions that combine technologies to create a broad based award winning platform for teleportation of our quantum entangled states while we injest our daily dose of vitamins to counter the effects of long term exposure to radionuclides emitted into our environment for with a full lifetime of hundreds of thousands of years. -- Patrick Shirkey Boost Hardware Ltd. ___ Linux-audio-dev mailing list Linux-audio-dev@lists.linuxaudio.org http://lists.linuxaudio.org/listinfo/linux-audio-dev
