And if I actually used my audio toys to make a living, I'd be all over Apple/OSX. The time saved by not having to dick with a bunch of broken software would more than offset the expense of the requisite hardware, OS, and commercial software.
But I don't. I make my living running the IT infrastructure of a successful multi-state enterprise, most of that built on open-source solutions running on Linux. So again, please spare us the condescending implication that anyone who doesn't want to deal with the mess that is Linux audio support is actually someone who can't. Do I know everything about Linux? Of course not. No one does. I certainly never claimed to. But I do know that if I had to deal with the type of disorganized mess that Linux audio support is in order to accomplish, say, the task of running an enterprise class mail server, I'd be looking for other solutions.
But I don't, because the support for the hardware involved in moving/managing email is all but invisible. It just works. And the software that actually handles the mail? It just works too. Not that there isn't room for lots of tweaking, in order to support this or that special feature, or to enhance performance/security/etc. Even then, however, the work involved is typically straightforward and well documented.
It is, perhaps, important to note here that this is the case because the developers who have contributed to the various projects that make up the tools that go into an open-source email platform have worked together to ensure interoperability. We do not see anywhere near that level of cooperation in the community of Linux audio developers. There is far too much fragmentation; multiple projects aimed at accomplishing the same task, usually with very different and of course, incompatible approaches.
Agreed, but again, there is no reason that this needed to be the case. We can lay many of the hardware problems squarely at the feet of the manufacturers who, all too often, refuse to provide support for their products. Video suffers as much as audio, if not more so. So why are there nowhere near this many issues for, say, storage and networking hardware under Linux? Where are the initiatives to draft standards that will eliminate, or at least minimize these issues?
Hi folks.
Instead of shaping up the Wiki I am playing with other little toys.
My headphones! (I just bought a new pair - "in-ears" - replacing my Etymotics ER4S )
I read some time ago that by adding binaural filters, the stereo image of your headphones would build up slightly in front of you, with a bit more realistic stage. These filters would also reduce stress on your brain - sounds tempting doesn't it? I thought I'd give it a try on a rainy Sunday afternoon.
After a little reading today I stepped over the "Bauer stereophonic-to-binaural DSP" open source solution, which you can make work pretty simple under Linux:
More reading:
Bauer stereophonic-to-binaural DSP
HowTo:
The tar file can be dowlnoaded here:
Browse Bauer stereophonic-to-binaural DSP Files on SourceForge.net
Download libbs2b-3.1.0.tar.gz
It installs quite well you just need to install libsndfile-dev
You'll find two binaries: bs2bconvert bs2bstream
bs2bconvert is a standalone converter and bs2bstream you can use in a pipe setup. The stream app gives you plenty of possibilities to incorporate it into
apps like MPD, SqueezeBoxServer,......
(There is even a LADSPA and a vst plugin available.)
Lets do first some tests, to see how it performs.
Find out your options by typing
bs2bconvert --help
e.g. to apply the default setting just run
bs2bconvert in.wav out.wav
Now. I tried all 3 modes - default,meier,moy.
Summary: I liked "meier" best.
To explain what kind of effect I experienced.
If you normally have the feeling that music is played at 1200-1300 (1200=top/center of your head, and 0900=tip of your nose).
The music seems to shift to 1130. It is not what I'd call day and night.
Anyhow it is a slight improvement.
The backside - first impression after 10 minutes of listening:
There are nasty filtering side-effects. The filters really seem to mess around with the data. You'll face quite some "losses" compared to the base material.
I'd consider it similar to a 128kbits mp3 - you seem to loose details at all angles. Sound stage collapses. Reverberation gets heavily cut off, etc. ( This shouldn't stop you from trying it. )
Perhaps I've done something wrong here. But if that's really it - there is no way I'd use that kind of filter. I also read the e.g. earwax from Sox is supposed to be much worse - I didn't try it by myself though.
Did anybody run similar tests? Can you confirm what I experienced? Your conclusions?
Are there better solution then the one above? E.g. Brutefir&Binaural Filter?
Cheers
Instead of shaping up the Wiki I am playing with other little toys.
My headphones! (I just bought a new pair - "in-ears" - replacing my Etymotics ER4S )
I read some time ago that by adding binaural filters, the stereo image of your headphones would build up slightly in front of you, with a bit more realistic stage. These filters would also reduce stress on your brain - sounds tempting doesn't it? I thought I'd give it a try on a rainy Sunday afternoon.
After a little reading today I stepped over the "Bauer stereophonic-to-binaural DSP" open source solution, which you can make work pretty simple under Linux:
More reading:
Bauer stereophonic-to-binaural DSP
HowTo:
The tar file can be dowlnoaded here:
Browse Bauer stereophonic-to-binaural DSP Files on SourceForge.net
Download libbs2b-3.1.0.tar.gz
It installs quite well you just need to install libsndfile-dev
Code:
sudo apt-get install libsndfile-dev checkinstall build-essential
sudo cp libbs2b-3.1.0.tar.gz /usr/src
cd /usr/src
sudo tar xvvf libbs2b-3.1.0.tar.gz
cd libbs2b-3.1.0
sudo configure --prefix=/usr
sudo make
sudo checkinstall # just enter libbs2b-3.1.0 as package name if being asked , and then use the default settingsYou'll find two binaries: bs2bconvert bs2bstream
bs2bconvert is a standalone converter and bs2bstream you can use in a pipe setup. The stream app gives you plenty of possibilities to incorporate it into
apps like MPD, SqueezeBoxServer,......
(There is even a LADSPA and a vst plugin available.)
Lets do first some tests, to see how it performs.
Find out your options by typing
bs2bconvert --help
e.g. to apply the default setting just run
bs2bconvert in.wav out.wav
Now. I tried all 3 modes - default,meier,moy.
Summary: I liked "meier" best.
To explain what kind of effect I experienced.
If you normally have the feeling that music is played at 1200-1300 (1200=top/center of your head, and 0900=tip of your nose).
The music seems to shift to 1130. It is not what I'd call day and night.
Anyhow it is a slight improvement.
The backside - first impression after 10 minutes of listening:
There are nasty filtering side-effects. The filters really seem to mess around with the data. You'll face quite some "losses" compared to the base material.
I'd consider it similar to a 128kbits mp3 - you seem to loose details at all angles. Sound stage collapses. Reverberation gets heavily cut off, etc. ( This shouldn't stop you from trying it.
)Perhaps I've done something wrong here. But if that's really it - there is no way I'd use that kind of filter. I also read the e.g. earwax from Sox is supposed to be much worse - I didn't try it by myself though.
Did anybody run similar tests? Can you confirm what I experienced? Your conclusions?
Are there better solution then the one above? E.g. Brutefir&Binaural Filter?
Cheers
I think the main issue will be to get a reasonable filter-coeff file. This you won't find in AlmusVCU. If we'd have the coefficients we could try it with brutefir. Perhaps we should ping Uli on that subject.
If you'd like to do some further experiments, there is a publicly available binaural recording of the impulse response of an empty concert hall. You could convolve it in BruteFIR and check out the result with headphones. The site is: Concert Hall Impulse Responses - Pori, Finland
And the binaural zip file url is: http://www.acoustics.hut.fi/projects/poririrs/wavs/binaural.zip
I did, though rather quickly. Tried also "earwax" from sox. Conclusion basically same as yours. No way.
I'm still unable to listen through head/earphones, can't stand that "sound in the head" feeling.
Those tricks didn't really helped with that but definitely worsened the sound.
Hi,
I'm struggling with piping from mpd to brutefir. What happens is this:
This is the input part in brutefir_config_
and this the corresponding part in mpd.conf:
Brutefir (v 1.0k) alone is running, as well as mpd (0.15.8) is playing music through alsa. mpd is compiled using 'pipe' as an output option.
Kernel is the current gentoo rt-sources (2.6.33.1-rt11)
If someone has a clue....
Rüdiger
I'm struggling with piping from mpd to brutefir. What happens is this:
Code:
Apr 06 23:58 : output: opened plugin=pipe name="brutefir" audio_format=44100:16:2
Apr 06 23:58 : client: [0] command returned 0
Apr 06 23:58 : client: [0] process command list
Apr 06 23:58 : command_process_list: process command "status"
Apr 06 23:58 : command_process_list: command returned 0
Apr 06 23:58 : command_process_list: process command "stats"
Apr 06 23:58 : command_process_list: command returned 0
Apr 06 23:58 : client: [0] process command list returned 0
Apr 06 23:58 : output: "brutefir" [pipe] failed to play: Write error on pipe: Broken pipe
Apr 06 23:58 : output: closed plugin=pipe name="brutefir"This is the input part in brutefir_config_
Code:
input "l_in", "r_in" {
device: "file" { path: "/dev/stdin"; };
...and this the corresponding part in mpd.conf:
Code:
audio_output {
type "pipe"
name "brutefir"
command "brutefir 2>/dev/null"
enable "yes"
format "44100:16:2"
}Brutefir (v 1.0k) alone is running, as well as mpd (0.15.8) is playing music through alsa. mpd is compiled using 'pipe' as an output option.
Kernel is the current gentoo rt-sources (2.6.33.1-rt11)
If someone has a clue....
Rüdiger
I agree - however, there are lots of factors in building a complete solution. I think the counter argument would simply be that a Windows solution would probably involve purchasing some convolver app and perhaps some other packages and I haven't checked, but I wouldn't be surprised if you told me it was a few hundred £s to purchase all that software?
Actually as someone who has hacked on the 9632 kernel driver, the missing facilities to get the kernel mixer and hdsp mixer in sync amount to just a small amount of code. I am backed up with other projects and it's not something which worries me (sorry, but I manage fine without the hdspmixer app at all...), but I wouldn't be surprised to find that you couldn't spend your few hundred £s employing a programmer to write the missing features for you (should pay for 2 days of coding, which is about all it requires)
So, here is the classic dilemma of opensource vs closedsource - it's not about price, its about the ability to own the whole thing and modify it to meet your needs. With the 9632 *linux* driver you own all the code and if you want to do something like say adding a new feature such as the ability for the Kernel code to talk to the hdspmixer application (something not in the original app), then you can employ a programmer to make this change for you.
Compare with the closed source alternative, eg try and modify the RME Fireface and for example make that mixer talk to your application... Oh, what's that you say, there isn't even a driver or published specifications to make the card work under your operating system... Oh, too bad then...
Don't misunderstand, neither answer may feel ideal to you. Different strokes and all that...
Now, you also mentioned Ubuntu allowing closed source and paid apps on their app store. I think the "paid for" bit is very welcome because revenue streams are often conducive to encouraging innovation. The closed source (non "free") bit is less welcome for ideological reasons...
I think people confuse "Free" code with "free" code. "Free" means you buy it and own it. "free" means it costs nothing, but possibly you don't own it. They are not one and the same thing. In fact "Free" code can cost significant amounts of money...
Eg, I used to buy a lot of Borland development products back before we had "Free" software. Borland used to give you nearly all the source code for their development tools, and this was tremendously useful. However you also had to pay for the development tools, which again was very reasonable. The point being that "Open" doesn't have to mean that it costs no money...
So in conclusion, yes there is a lot of cr*ppy "Free" and "free" software, but try to encourage "Free" because it gives you a lot of extra rights that are missing with closed source software. The soundblaster/vista fiasco should be enough to remind people why closed source is not necessarily aligned with your interests...
@ Rüdiger
Below worked for me last time I tried it.
Brutefir config-file example:
Note: S32_LE format was required. Otherwise brutefir were not able to read the data from mpd.
Good luck.
Below worked for me last time I tried it.
Code:
audio_output {
type "pipe"
name "pipe-brutefir-4416"
format "44100:16:2"
command "brutefir -nodefault /path-to-yourconf/brut/brutconf4416-pipe 2>/dev/null"
enable "no" }Brutefir config-file example:
Code:
device: "file" {path: "/dev/stdin"; };
sample: "S32_LE"; # sample formatNote: S32_LE format was required. Otherwise brutefir were not able to read the data from mpd.
Good luck.
@edwildgoose
The whole discussion is a matter of who's considered the "targeted" target group for Linuxes like Ubuntu and Linux Mint and Fedora and Suse ......
Shuttleworth just announced that with Ubuntu 10.10 in October he expects his Linux to be on the same level as Windows. So the target group is clear - isn't it. No more hacker-land!
I do see a huge gap between reality and his vision though. Of course he needs to push his message out to the world if he really intends to make sales with his app-store.
I tell you he'll fail on that one. He just still havn't understood what's wrong with Linux and that he won't get it solved until October 2010 and not until October 2011. He tries to built his house on sand. This won't work. He just missed to built a solid fundament first - and I consider a rock solid working multimedia environment incl. hw vendor commitments a key fundamental issue which need to be addressed first. Something like that will break his neck.
When it comes to financing opensource projects and the guys behind it. As
you might have realized a lot of opensource programmers put a "DONATE"
button on their homepage. From what I know/read people are willing to spent the "appropriate" amount of cash. If people feel they get value for the money they pay for it. Of course they'd expect a certain commitment of that programmer. You can learn a lot form the Apple app-store community here. Through the user feedback you can't afford to mess with your customers even if your app just cost 2$ there is an underlying quality an maintenance commitment between you and your customer. This is the least what people expect if they pay for SW. Paying you just two days of work won't work. If you takeover full responsibility on commitment for that driver. People would pay you for this or that new valuable feature or certain maintenance. You could even get much closer to RME by being the Linux guy in charge for their stuff.
When it comes to RME support. They sell - I don't know how many devices I'd guess a lot - to Linux people. What would it cost them to assign a designer (even anonymously) for a couple of days to get the code straight. They would sell many more products by actively supporting Linux - that's for sure. The OSX code is even there. What's the issue?
Anyhow we won't change the world by talking about it over here.
Cheers
The whole discussion is a matter of who's considered the "targeted" target group for Linuxes like Ubuntu and Linux Mint and Fedora and Suse ......
Shuttleworth just announced that with Ubuntu 10.10 in October he expects his Linux to be on the same level as Windows. So the target group is clear - isn't it. No more hacker-land!
I do see a huge gap between reality and his vision though. Of course he needs to push his message out to the world if he really intends to make sales with his app-store.
I tell you he'll fail on that one. He just still havn't understood what's wrong with Linux and that he won't get it solved until October 2010 and not until October 2011. He tries to built his house on sand. This won't work. He just missed to built a solid fundament first - and I consider a rock solid working multimedia environment incl. hw vendor commitments a key fundamental issue which need to be addressed first. Something like that will break his neck.
When it comes to financing opensource projects and the guys behind it. As
you might have realized a lot of opensource programmers put a "DONATE"
button on their homepage. From what I know/read people are willing to spent the "appropriate" amount of cash. If people feel they get value for the money they pay for it. Of course they'd expect a certain commitment of that programmer. You can learn a lot form the Apple app-store community here. Through the user feedback you can't afford to mess with your customers even if your app just cost 2$ there is an underlying quality an maintenance commitment between you and your customer. This is the least what people expect if they pay for SW. Paying you just two days of work won't work. If you takeover full responsibility on commitment for that driver. People would pay you for this or that new valuable feature or certain maintenance. You could even get much closer to RME by being the Linux guy in charge for their stuff.
When it comes to RME support. They sell - I don't know how many devices I'd guess a lot - to Linux people. What would it cost them to assign a designer (even anonymously) for a couple of days to get the code straight. They would sell many more products by actively supporting Linux - that's for sure. The OSX code is even there. What's the issue?
Anyhow we won't change the world by talking about it over here.
Cheers
I think you are punching air. I *agree* with you wholeheartedly that it would be great if linux audio worked even better "out of the box"!
However, the world is full of compromises. The real world is full of corner cases and strange use patterns. There are a load of people frustrated with OSX and Windows audio, so don't assume that either of these is perfect either... All we can do is improve the status quo and make things better for as large a group of people as possible. Just because Windows works better for your use case doesn't make it best for mine!
Right now Linux audio is working out of the box *for me*. I don't dispute that it's not working for you, I just point out that I have different needs to you - nothing else. A large part of the basis of the linux community is that of choice, so don't feel you need to only use linux... Personally I use a mix of stuff here including Linux, Windows (XP -> Win7) and OSX - use the appropriate tool and all that
So given that opinions are 2 a penny and everyone has one.. My opinion is simply that the rate of change on this stuff on Linux is very great (and windows is progressing very slowly). I often think that people who cry that windows is best have either not used earlier versions of windows, or forgotten exactly what they had to go through before it all worked perfectly. Perhaps even you bought your machine with the software pre-installed (eg a pre-installed laptop) and hence you never needed to go through all the pain of finding the right drivers for your hardware?
I have a couple of home-brew machines here and they have all been at least a medium amount of pain to get all the drivers up and running. My audio card still clicks and stutters on my Vista machine (never bothered to figure out how to fix it). I have two win7 machines (32bit/64bit) running as virtual machines and both click and dropout the audio when the machine is loaded (eg booting up sounds horrible with lots of clicks and pops as it plays the annoying login noise). Also before Vista did you see the hoops you needed to jump through to avoid kmix resampling your audio for you? (usually very badly resampling it) High quality audio had a LOT of issues on XP (and check out the RME forums about the Fireface 400 before you tell me too much more about RME windows support being the bees knees...)
My Macbook Pro is fine for sound, but I do get lots of other random gremlins from screen flickers, suspend failures, lockups, bluetooth randomly stops working, network drives lock up, etc, etc...
I really don't want to argue that one OS is better than the other, but I will claim that:
- they are *all* less good than I would like!
- Linux has a very healthy pace of improvement, if we optimistically assume this will improve and extrapolate forward then the future looks good for having 3 great operating systems to choose for your next computer!
However, the world is full of compromises. The real world is full of corner cases and strange use patterns. There are a load of people frustrated with OSX and Windows audio, so don't assume that either of these is perfect either... All we can do is improve the status quo and make things better for as large a group of people as possible. Just because Windows works better for your use case doesn't make it best for mine!
Right now Linux audio is working out of the box *for me*. I don't dispute that it's not working for you, I just point out that I have different needs to you - nothing else. A large part of the basis of the linux community is that of choice, so don't feel you need to only use linux... Personally I use a mix of stuff here including Linux, Windows (XP -> Win7) and OSX - use the appropriate tool and all that
So given that opinions are 2 a penny and everyone has one.. My opinion is simply that the rate of change on this stuff on Linux is very great (and windows is progressing very slowly). I often think that people who cry that windows is best have either not used earlier versions of windows, or forgotten exactly what they had to go through before it all worked perfectly. Perhaps even you bought your machine with the software pre-installed (eg a pre-installed laptop) and hence you never needed to go through all the pain of finding the right drivers for your hardware?
I have a couple of home-brew machines here and they have all been at least a medium amount of pain to get all the drivers up and running. My audio card still clicks and stutters on my Vista machine (never bothered to figure out how to fix it). I have two win7 machines (32bit/64bit) running as virtual machines and both click and dropout the audio when the machine is loaded (eg booting up sounds horrible with lots of clicks and pops as it plays the annoying login noise). Also before Vista did you see the hoops you needed to jump through to avoid kmix resampling your audio for you? (usually very badly resampling it) High quality audio had a LOT of issues on XP (and check out the RME forums about the Fireface 400 before you tell me too much more about RME windows support being the bees knees...)
My Macbook Pro is fine for sound, but I do get lots of other random gremlins from screen flickers, suspend failures, lockups, bluetooth randomly stops working, network drives lock up, etc, etc...
I really don't want to argue that one OS is better than the other, but I will claim that:
- they are *all* less good than I would like!
- Linux has a very healthy pace of improvement, if we optimistically assume this will improve and extrapolate forward then the future looks good for having 3 great operating systems to choose for your next computer!
Look, the Linux "advantage" is more that you *can* customise it for the corner cases.
I really don't think we should spend time arguing the toss over the "average case" because that likely favours either windows or OSX and the exact choice will come down to what you need to do.
You can read about my setup on Main Page - DRC - basically linux audio has allowed me to integrate a bunch of stuff together that would not have been possible some years back on Windows and possibly still isn't easy to do (yes I can write code - if you can't then probably this option would not have worked for you - no argument there - but it was ok *for me* and let me do something that would have been extremely difficult/impossible on Windows)
Actually, thinking about it OSX is a great example in point of how (at least to my eye) it makes the average case as simple as possible, but at the expense of the corner case. eg Buy a Mac Mini and you have iTunes and apple audio working out of the box. However, now try and play some FLAC tunes on your box... Erk, ok, start recoding them. OK, now start shuffling the files around onto a NAS so that you can play them on other devices. Now try and integrate other non apple output devices, eg stream synced audio to a range of devices around the home...
I use a Macbook Pro as my main laptop and it does do the easy stuff nicely, but it drives me nuts trying to make the less common stuff work the way I want... Windows feels somewhere in the middle. And for me Linux tends to be the most tweakable, but sometimes the least easy to get stuff done out of the box.
Pick your tool and be happy!
I really don't think we should spend time arguing the toss over the "average case" because that likely favours either windows or OSX and the exact choice will come down to what you need to do.
You can read about my setup on Main Page - DRC - basically linux audio has allowed me to integrate a bunch of stuff together that would not have been possible some years back on Windows and possibly still isn't easy to do (yes I can write code - if you can't then probably this option would not have worked for you - no argument there - but it was ok *for me* and let me do something that would have been extremely difficult/impossible on Windows)
Actually, thinking about it OSX is a great example in point of how (at least to my eye) it makes the average case as simple as possible, but at the expense of the corner case. eg Buy a Mac Mini and you have iTunes and apple audio working out of the box. However, now try and play some FLAC tunes on your box... Erk, ok, start recoding them. OK, now start shuffling the files around onto a NAS so that you can play them on other devices. Now try and integrate other non apple output devices, eg stream synced audio to a range of devices around the home...
I use a Macbook Pro as my main laptop and it does do the easy stuff nicely, but it drives me nuts trying to make the less common stuff work the way I want... Windows feels somewhere in the middle. And for me Linux tends to be the most tweakable, but sometimes the least easy to get stuff done out of the box.
Pick your tool and be happy!
Of course it is good to have different opinions, perspectives, background, intentions, etc. These "punching air" discussions I actually consider quite interesting and constructive.
However. You must be considered a hacker. I consider myself a hacker. And phofman and several others who contribute over here quite often will also join the club. We don't belong to the earlier discussed target group of Shuttleworths' mass market!
Start discussing your DRC page at AudioAsylum. This group will refer you to Thunaeu Allocator - More or less a Plug'n Play approach. They just won't touch the command line or any other rather complex or buggy solutions.
This discussion is not meant to be a complaint about Linux. It's meant to be a realistic view on what's there and some peoples very ambitious targets to address the mass market with what's there until Q3/2010.
In terms of audio shortages I am referring to people - simple straight forward users I am in contact with at Ubuntu forums, where I maintain sporadically an Alsa upgrade script for the community, and e.g. Audio Asylum.
Exactly this experience over there shows me what's wrong with Linux audio. One of the key issues is IMO the gap between availability of drivers at Alsa
and its final availability to Linux users. It's not enough that drivers are not developed at all or developed with a stripped down feature set years later then the OSX/MS pendants, no, if they are available they get to you as a normal user up to another year later, because they are tight to the kernel and distro cycles.
This would be the first thing I'd change, this is IMO unacceptable. Firefox gets updated every 2nd week. What's the issue to update a couple of modules every other month? There is IMO none.
I better leave it for now.
Cheers
However. You must be considered a hacker. I consider myself a hacker. And phofman and several others who contribute over here quite often will also join the club. We don't belong to the earlier discussed target group of Shuttleworths' mass market!
Start discussing your DRC page at AudioAsylum. This group will refer you to Thunaeu Allocator - More or less a Plug'n Play approach. They just won't touch the command line or any other rather complex or buggy solutions.
This discussion is not meant to be a complaint about Linux. It's meant to be a realistic view on what's there and some peoples very ambitious targets to address the mass market with what's there until Q3/2010.
In terms of audio shortages I am referring to people - simple straight forward users I am in contact with at Ubuntu forums, where I maintain sporadically an Alsa upgrade script for the community, and e.g. Audio Asylum.
Exactly this experience over there shows me what's wrong with Linux audio. One of the key issues is IMO the gap between availability of drivers at Alsa
and its final availability to Linux users. It's not enough that drivers are not developed at all or developed with a stripped down feature set years later then the OSX/MS pendants, no, if they are available they get to you as a normal user up to another year later, because they are tight to the kernel and distro cycles.
This would be the first thing I'd change, this is IMO unacceptable. Firefox gets updated every 2nd week. What's the issue to update a couple of modules every other month? There is IMO none.
I better leave it for now.
Cheers
Blimey, if this is what the windows users are holding up as an example of an "easy to use" application then it should be pretty easy to beat...!
....I'm not even sure *I* know how to plug in all the params to that program?!!!
Certainly apart from the author choosing not to support Linux I see no great reason why this app *couldn't* be written very easily to work on Linux. He simply needs build it as a LADSPA plugin and your work is pretty much done in that it will work everywhere Alsa works (lets not debate that bit...).
I have contributed some code to a cross platform audio library and if you think that it's easier to program audio on windows than Alsa/Oss/Jack then you need to go out and research this some more... Actually, just for kicks go and release an audio application which relies on ASIO and see how many windows machines it works flawlessly on... (Or at least this is what I found a few years ago, perhaps it's suddenly improved a bunch in the last couple of years - point is still valid though). If your userspace application doesn't bluescreen at least a few of them then you were doing better than me...!
As an aside, with regards to your Alsa comment. Why do you say Alsa can't be upgraded weekly? The code is all public and if your distribution uses alsa in a modular fashion then someone like yourself could make regular builds of the alsa drivers from upstream and release them as a weekly updateable package for your target operating system?
I don't expect most users to need to do this, but I thought your point was whether it's possible? I certainly can't see why someone (say Canonical or yourself) couldn't do it if they thought there was some business model that made it beneficial?
In contrast (and again I think the whole premise is dubious, but...) try and do the same thing on Windows. ie update all the drivers for a whole class devices and publish those new drivers weekly... Hmm...
Anyway, there is no disagreement from me that Linux needs more work in this area, but do look less at where it is today and more at where it was a few years ago and the pace of progress between now and then. Just do something else for a year or two and check back - I think it's evolving at a very fast pace right now and probably much faster than the competition
OK, lets get back onto solving specific problems though. We seem to be punching air again
I hope you understand that you don't have to convince me about Linux audio - I
love it, since quite a while. And I am pushing it As much as I can.
I would actually like to see more people on Linux.
But I am not that narrow minded to ignore certain crucial issues which prevents people to give Linux a serious try.
love it, since quite a while. And I am pushing it As much as I can.
I would actually like to see more people on Linux.
But I am not that narrow minded to ignore certain crucial issues which prevents people to give Linux a serious try.
Neither your proposal, nor any other config variation works on my machine. It's alway that 'broken pipe' error. Seems, if I ever want to use brutefir, I shall switch to another player. Which isn't good, because I find the client/server approach appealing, and am in fact organized to use mpd. So, no room correction or other fancy playground for me at the moment.
Rüdiger
I have this in my mpd.conf
and this in .brutefir.config.pipe
and it works
i think the -nodefault option and the full path to the .brutefir.config file are important otherwise brutefir search for this file and .brutefir_default in the directory where it was launched and when it is launched by mpd is not clear where it search for this files (at least to me)
ciao
andrea
Code:
audio_output {
type "pipe"
name "mpd-pipe"
command "/usr/local/bin/brutefir -nodefault /home/andrea/.brutefir_config.pipe 2> /home/andrea/DRC/brutefir.log
format "44100:32:2"
}and this in .brutefir.config.pipe
Code:
input "lin", "rin" {
device: "file" {path: "/dev/stdin"; };
sample: "S32_LE"; # sample format
channels: 2;
};and it works
i think the -nodefault option and the full path to the .brutefir.config file are important otherwise brutefir search for this file and .brutefir_default in the directory where it was launched and when it is launched by mpd is not clear where it search for this files (at least to me)
ciao
andrea
Last edited:
@anbello:
Your 32 bit config on the format parameter also worked when I tried it some time back. (I just looked it up on my old Wiki pages-I had described it over there)
Also very important on that pipe command is that you route the errors to 2>/dev/null or to a log file.
@ Juergen:
1.
Your chosen setup: Gentoo+2.6.33-rt and whatever Alsa you'll pretty much on your own over here and anywhere else I'd guess. That makes support not easier for most of the people around here. Gentoo is a Hacker-Distro, you need to have in-depth knowledge to get it under control.
However this might not be the actual reason for your problems.
You might also need to play around with the settings such as buffer sizes etc. You could also prelink the brutefir and associated binaries so that it starts up faster. You could also apply
realtime priorities to brutefir: schedtool -F -p 80 -e brutefir .....
Don't believe the things I am or others are writing up /or have written up are done in a minute.
A little project like the "mpd-pipe" issue took me hours of googling, posting and trying to get it working.
I am honestly not very motivated to install myself a MPD again to see how it is going nowadays.
SINCE:
2.
I am running SqueezeBox Server and Squeezslave (as daemon on my Linux machines) beside my Squeezeboxes in the network. I consider SBS much better then MPD - at least for my purposes. The only downside is that Squeezslave is just 44.1/48/16 for now.
You can easily integrate brutefir into SBS. As I mentioned earlier - there are not very many controllers for it - though with iPeng as remote I am 100% satisfied.
Good luck.
Cheers
Your 32 bit config on the format parameter also worked when I tried it some time back. (I just looked it up on my old Wiki pages-I had described it over there)
Also very important on that pipe command is that you route the errors to 2>/dev/null or to a log file.
@ Juergen:
1.
Your chosen setup: Gentoo+2.6.33-rt and whatever Alsa you'll pretty much on your own over here and anywhere else I'd guess. That makes support not easier for most of the people around here. Gentoo is a Hacker-Distro, you need to have in-depth knowledge to get it under control.
However this might not be the actual reason for your problems.
You might also need to play around with the settings such as buffer sizes etc. You could also prelink the brutefir and associated binaries so that it starts up faster. You could also apply
realtime priorities to brutefir: schedtool -F -p 80 -e brutefir .....
Don't believe the things I am or others are writing up /or have written up are done in a minute.
A little project like the "mpd-pipe" issue took me hours of googling, posting and trying to get it working.
I am honestly not very motivated to install myself a MPD again to see how it is going nowadays.
SINCE:
2.
I am running SqueezeBox Server and Squeezslave (as daemon on my Linux machines) beside my Squeezeboxes in the network. I consider SBS much better then MPD - at least for my purposes. The only downside is that Squeezslave is just 44.1/48/16 for now.
You can easily integrate brutefir into SBS. As I mentioned earlier - there are not very many controllers for it - though with iPeng as remote I am 100% satisfied.
Good luck.
Cheers
Hi folks.
Is anybody aware of a little command line tool which converts volume in 64bit double precision and adjusts in db stepping?
Under windows you'll find more and more tools which run DSP work in 64bit throughout the entire DSP chain.
Sox is afaik 32bit.
Ecasound is 32bit.
brutefir is 64bit - at least the filters are doubles - but I guess the VC too?
I'd just need a simple offline tool which is able to handle .wav in 16/44.1 for testing.
THX
Is anybody aware of a little command line tool which converts volume in 64bit double precision and adjusts in db stepping?
Under windows you'll find more and more tools which run DSP work in 64bit throughout the entire DSP chain.
Sox is afaik 32bit.
Ecasound is 32bit.
brutefir is 64bit - at least the filters are doubles - but I guess the VC too?
I'd just need a simple offline tool which is able to handle .wav in 16/44.1 for testing.
THX
I case you are talking to me, I disagree. I choose gentoo on purpose, although it needs more learning, the returns are wealthy, because the available online information sources are comprehensive.
It took me a while to understand and set up a custom installation, but now I have a very fast and very stable system with no single unsolved driver issue (afaik).
Brutefir is running now (there were at least two mistakes in the mpd.config I posted), so I'm ready to go further with setting up RC-filters.
Btw, is there a simply wav-editor that doesn't need X-windows out there? I need it to cut ends and beginnings of captured analog sources.
Rüdiger
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.