Experiment

Programming applications for making music on Linux.

Moderators: MattKingUSA, khz

falken
Established Member
Posts: 21
Joined: Mon Sep 02, 2013 1:28 am

Re: Experiment

Post by falken »

umm, having opened 10 tabs binged/googled (rather binged honestly, since google disalowed + and - on phrases, grrrr) I found that HWDEP is used to configure and control custom nonstandard parts of eighter quite legacy consumer adapters equiped by HW synth chips as FM OPL/YMU or programmable DSP as EMU 10K or even quite standard ADSP-2115 (I personally owned such card Paradise 16-DSP from Western Digital, back in 1993 or so, great design, really, loved it even that GUS was famous at this time; there was REAL 20MIPS DSP !!!) to upload DSP firmware code, or on the other side for few true professional adapters as RME does to configure onboard complex monitoring mixes, onboard FXs etc... All this quite legacy at all today, having far more documented "audio class" standards particulary for USB (1.0 mostly consumer but useable for profi and 2.0 HS even profi considered finally);
So this is also reason why I LOVE such standardized usb-audio classes and their fully implemented drivers (as in Windows its better than in linux, together with all related drivers for latest USB bus topology/hubs/multi-TT etc)

but honestly, NO systematic real documentation about the subject, only "exactly 1" real sample code here:
http://jan-holst.dk/u2a-control/index.html
http://www.mail-archive.com/alsa-devel@ ... 12813.html (also something meaningfull)
2005-09-07
Here I am, at it again after the summer holidays. A patch by ALSA-developer Clemens Ladisch for the USB audio driver implements a hardware dependant interface that allows me to send control transfers to the device through an ioctl() call (please note that this patch only applies cleanly to an older CVS version of the ALSA drivers). I have been able to squirt off a control transfer package to the sound card without getting an error code back, so that definitely counts as progress :-). See below for a useless example that nevertheless seems to send two bytes without complaints.
UMM,
I like to see concepts first, big picture, may be even real pictures and drawings, diagrams, may be videos first. Then short conceptual description how things relates together, then details and for sure, also deep internals and reasons WHY things are implemented the specific way (mostly I understand WELL based on the "inside" details - big woohoo, yeeaah comes :-). But developers have no time to do docs, OK. There arent resources to pay for it, OK. SO...

May be, as LINUX really is OSS and here code is considered as BEST documentation (ummm, good code, well) then at least, can there be some project which integrates at least BIG-PICTURES, birds view in short presentations/videos with graphics and links to compact conceptual description (WIKIs) which will be deeply linked to particular OSS codebases (SVN/GIT/...) exactly to show EXAMPLES how things are really used??? At least this way???

Cheers,
Petr
carlc
Posts: 1
Joined: Wed Sep 04, 2013 1:43 pm

Re: Experiment

Post by carlc »

Hi Jeff,

I found your thread earlier this week through Google as I've been asked to evaluate Linux as an alternate platform for a Windows application. As the application was to remain cross platform and maintain an indentical user experience everywhere, it does not make much sense to use Jack considering the poor state of Jack on Windows, so absent any implementation of important Jack features it only makes sense to hook the apps existing audio device configuration dialogs into ALSA the same way that the application uses ASIO or WASAPI today.

So I asked the ALSA developers to add to their todo list an additional example application in ALSA SDK tarball to eliminate uncertainty about how a full duplex + MIDI application should be implemented.

http://mailman.alsa-project.org/piperma ... 66085.html

Less than 24 hours later I have now shown the mailing list thread to my corporate masters, who had a hearty laugh with me and decided maybe a Linux port isn't such a good use of our time. This has the side effect of tabling any further discussion of making any part of the application open source as ASIO and VST have restrictive licenses that prevent open sourcing the application unless you first strip out any references to ASIO. So absent any open source back end to port to, there is little reason to even consider open sourcing any code. If ALSA has a monopoly on Linux audio then we want nothing to do with Linux, nor do we want Jack or any other API to act as a wrapper between ALSA.

BTW I only registered this user name to comment in your thread, I won't be returning to read replies or spending any more time evaluating ALSA or Jack so any calls by loyalists to give Jack another chance will fall on deaf ears, we've moved on to other projects now.

Warm Regards,
Carl
User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

Re: Experiment

Post by raboof »

carlc wrote:it does not make much sense to use Jack considering the poor state of Jack on Windows, so absent any implementation of important Jack features it only makes sense to hook the apps existing audio device configuration dialogs into ALSA
Indeed it does not make sense for carlc to use JACK on Windows. It does, however, make sense to use JACK (instead of ALSA) on Linux. This is the advice he received on the ALSA mailinglist, too - I don't understand why he insists on using ALSA directly.
http://mailman.alsa-project.org/pipermail/alsa-devel/2013-September/066103.html wrote:t is my personal conviction that I would much rather retain full control of my application by communicating directly with ALSA rather than delegating control to Jack just to ease the pain of deciphering your poor documentation.
This is of course nonsense: the reason to prefer JACK over ALSA is not that ALSA has poor documentation.
absent any open source back end to port to
JACK is right there.
I won't be returning to read replies or spending any more time evaluating ALSA or Jack
I was tempted to moderate away this message as this indicates there's little hope for a useful discussion, but let's see.
ssj71
Established Member
Posts: 1294
Joined: Tue Sep 25, 2012 6:36 pm
Has thanked: 1 time

Re: Experiment

Post by ssj71 »

I think it is important to note that JACK is not a wrapper, but an interface.
_ssj71

music: https://soundcloud.com/ssj71
My plugins are Infamous! http://ssj71.github.io/infamousPlugins
I just want to get back to making music!
tramp
Established Member
Posts: 2348
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 468 times

Re: Experiment

Post by tramp »

Image
On the road again.
j_e_f_f_g
Established Member
Posts: 2032
Joined: Fri Aug 10, 2012 10:48 pm
Been thanked: 358 times

Re: Experiment

Post by j_e_f_f_g »

carlc wrote:I've been asked to evaluate Linux as an alternate platform for a Windows application.
Hi Carl,

As a Windows music app developer who also does linux stuff, I feel your pain. Linux documentation is atrociously bad. I consider it linux's biggest weakness. And frankly, a bit of the advice you get from too many linux devs is equally uninformed, unhelpful, and unprofessional. You be amazed how appalling little a great many linux audio devs know about alsa.

The first thing youu should do is go read my linux audio programming article at http://home.roadrunner.com/~jgglatt/tech/linuxapi.htm . It's not finished yet. I did most of the midi stuff, but I just started the audio stuff. But that will get you started. Secondly, download the source to my EDrummer app at http://home.roadrunner.com/~jgglatt/edrummer.zip which is profusely commented (I am not a typical open source dev. My philosophy is 'If you don't document your source, then don't release it'). That app will show you how to get the tightest performance for midi input and output, and digital audio playback. The only base left to cover is audio recording, but you'll quickly figure that out after gleaning info from my tutorial and example code.
the same way that the application uses ASIO or WASAPI
I don't like ASIO. I do really like WASAPI's Exclusive mode, and to date, it's the best audio API I've used. Ain't gonna lie, Linux doesn't have anything to match wasapi in both ease of use and performance. With linux, you have to choose one or the other. You can choose alsa's mmap mode which, like wasapi exclusive mode, eliminates buffer copying, minimizes address translation, and gives direct access to hardware dma buffers. Is it designed well enough to be easily used? Hell no. It was written by a guy who takes data abstraction to absurd extremes, and thinks it's a great idea to provide a dozen different ways to do the same thing. He's what I call a "computer science programmer". No sense of practicality. What I can do in 6 lines of wasapi code literally takes dozens of lines of alsa code. The good news is alsa mmap will give you the performance of wasapi exclusive or asio. Even better if you use a optimized kernel vs stock Windows.

Or you can do things the lazy and easy way with jack, which has a simple api, but internally does craploads of buffer copying/mixing, socket reading/writing, and even inflicts process switching atop that mess. Will you get asio or wasapi exclusive performance? Hell no. Latency is atrocious in comparison. (You wouldn't believe the latency linux musicians readily accept. I either do all pro music work on Windows, or I use my own tools which use alsa).
I only registered this user name to comment in your thread, I won't be returning to read replies or spending any more time evaluating ALSA or Jack
You're hardly the first Windows dev who has come here (or to some linux forum) looking for info and interested in linux, listened to the "advice/recommendations/knowledge" of linux folks, then ended up shaking his head and saying "that ain't for me". How do I know? Because google seems to direct them to a lot of the content I post, and apparently resonates with them enough that they email me about it. I've gotten emails from 8 windows devs just through this here forum commenting on these threads and basically telling me how... um... "dissatisfied" they've been with just the process of researching linux, let alone anything more. I'm laughing because I just looked at the board index, and see I have a new email.

Bottom line: Linux dev docs need to vastly improve before more pro devs will partake.

Secondly, if your a linux dev who is using something like jack because it's "easy" and you don't know how to program "the hard stuff" because the docs are terrible and the example code is scarce and equally bad, then don't give advice to people who are willing to do the hard work. Trust me, that never goes well.

But if you stumble back here Carl, then I'll hook you up with the info/code you want.

Author of BackupBand at https://sourceforge.net/projects/backupband/files/
My fans show their support by mentioning my name in their signature.

tramp
Established Member
Posts: 2348
Joined: Mon Jul 01, 2013 8:13 am
Has thanked: 9 times
Been thanked: 468 times

Re: Experiment

Post by tramp »

It isn't as hard to find examples for audio interfacing with ALSA directly
http://sourceforge.net/p/faudiostream/c ... alsa-dsp.h
, just the interest under Linux Audio Developers in use it, is low, simply because the modular interfacing between applications is the focus we/they work on. If you would use ALSA for your app, do it, but don’t be surprised when you only get users which come fresh from windows, and when they disappear as soon they face the ability they get with jack.

just a tramp
On the road again.
User avatar
raboof
Established Member
Posts: 1855
Joined: Tue Apr 08, 2008 11:58 am
Location: Deventer, NL
Has thanked: 50 times
Been thanked: 74 times
Contact:

Re: Experiment

Post by raboof »

j_e_f_f_g wrote:Or you can do things the lazy and easy way with jack, which has a simple api, but internally does craploads of buffer copying/mixing, socket reading/writing, and even inflicts process switching atop that mess. Will you get asio or wasapi exclusive performance? Hell no. Latency is atrocious in comparison.
Indeed Jack introduces overhead in terms of resource utilisation - indeed there's buffer copying/mixing and process switching going on.

This does not neccessarily mean latency increases. It only means latency increases when the overhead is so big that you need to switch to bigger buffers. I haven't seen measurements that prove that's often the case for real-world DSP loads. I'll readily admit I haven't searched very well for such benchmarks, so if you could point to them I'd be interested.
j_e_f_f_g wrote:Secondly, if your a linux dev who is using something like jack because it's "easy" and you don't know how to program "the hard stuff" because the docs are terrible and the example code is scarce and equally bad, then don't give advice to people who are willing to do the hard work. Trust me, that never goes well.
I entirely agree you should not use Jack because it's easier (though it is). I think one should use Jack because it's what I prefer to use as an end-user.

I know you insist talking directly to ALSA would for some reason be better here, even though even ALSA developers themselves disagree. Not much sense in repeating that discussion again though.
falken
Established Member
Posts: 21
Joined: Mon Sep 02, 2013 1:28 am

Re: Experiment

Post by falken »

@all: thanks for the big-pictures and detailed internals on linux audio elsewhere;

One question, tried anybody to benchmark at least most complete(?) ardour somehow?
When I tried to b/g "ardourVST DAWbench", there is till now NOTHING to return, curious :-)
Post Reply