Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › The State Of Linux Audio
New Posts  All Forums:Forum Nav:

The State Of Linux Audio - Page 2

post #11 of 30
Quote:
Originally Posted by parityboy View Post
@mushroomboy

You're right in that all the programs I use can interface with ALSA. The problem is that dmix doesn't seem to work on my distro, and I need WINE and TeamSpeak to happily co-exist, audio-wise.

I also find that VLC generally does a better job of playing DVD .iso files than either MPlayer or Kaffeine; it handles the menus and navigation better. Additionally, the ALSA->PulseAudio plugin works fine with other applications, it just screws up with WINE, leading me to believe that WINE is actually the culprit.

What I don't understand is why the ALSA developers didn't bother to write a decent sound server when they developed the ALSA architecture. Something that combines the best of JACK (performance) and PulseAudio (features, like network audio). It would have been a natural fit.

Network audio, really has no place being in the audio server, persay. It should be a open node that a network service can latch onto. IE it should be part of the web services, not part of the audio server, but the 2 should be able to communicate.
post #12 of 30
Quote:
Originally Posted by parityboy View Post
@mushroomboy

You're right in that all the programs I use can interface with ALSA. The problem is that dmix doesn't seem to work on my distro, and I need WINE and TeamSpeak to happily co-exist, audio-wise.

I also find that VLC generally does a better job of playing DVD .iso files than either MPlayer or Kaffeine; it handles the menus and navigation better. Additionally, the ALSA->PulseAudio plugin works fine with other applications, it just screws up with WINE, leading me to believe that WINE is actually the culprit.

What I don't understand is why the ALSA developers didn't bother to write a decent sound server when they developed the ALSA architecture. Something that combines the best of JACK (performance) and PulseAudio (features, like network audio). It would have been a natural fit.
Xine works best with DVDs if you want a DVD player in Linux.

Again, Wine is not the culprit. The wine devs want full PCM control, they can't get that with a standard Pulse plugin. It would be a mess for them to write while they already have a perfect solution, the ALSA plugin. Wine outputs to ALSA flawlessly. [edit] I forgot, the pulse plugin for wine was a quick fix written by somebody. If you read the site info http://art.ified.ca/?page_id=40 you will find that 1) the plugin is redundent 2) it doesn't work.

As for your dmix "problem". If you can't purge PulseAudio and get dmix to work there is something wrong. Something very wrong, because ALSA should work. I've used the same distro and gotten everything purged and working. If you get sound, you'll get mixing. Now, I can't vouch for how well your audio hardware would work without Pulse but it should.
Edited by mushroomboy - 10/4/11 at 10:04pm
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
post #13 of 30
Thread Starter 
Quote:
Originally Posted by SCollins View Post
Network audio, really has no place being in the audio server, per se. It should be a open node that a network service can latch onto. IE it should be part of the web services, not part of the audio server, but the 2 should be able to communicate.
I'm no expert but I might have to disagree with you there. It sounds a bit like, "remote desktops have no place in the X server...".

I understand what your saying, but I would have thought that latency would play an issue if you introduce another entity. I would envision a modular architecture where the audio server has some kind of auto-discovery of other servers on the LAN, and treats them as another piece of audio hardware.

I'm not saying network audio is needed at all, but it would be a nice feature; Apple do some killer things with it.


Quote:
Originally Posted by mushroomboy View Post
Xine works best with DVDs if you want a DVD player in Linux.
You say that, but I can't get Xine to work with DVDs at all. Most of my DVDs are ISO files, and even mounting them via /dev/loop0 and configuring Xine accordingly simply does not work. It used to work when I ran Gentoo...

Quote:
I forgot, the pulse plugin for wine was a quick fix written by somebody
...
you will find that 1) the plugin is redundent 2) it doesn't work.
I was talking about the ALSA->PulseAudio plug-in, not the WINE->PulseAudio plugin. I configure .asoundrc to use the ALSA->PulseAudio plug-in, then tell WINE to use ALSA. The result is choppy audio in WINE.

Quote:
If you get sound, you'll get mixing. Now, I can't vouch for how well your audio hardware would work without Pulse but it should.
This may well be the issue, but I simply couldn't get it to work. I'm using Intel HD Audio built into the H55 chipset. Could you paste your .asoundrc as a template for me to follow? I'd appreciate it.
Edited by parityboy - 10/5/11 at 4:46pm
Ryzen
(12 items)
 
  
CPUMotherboardGraphicsRAM
Ryzen 7 1700 Gigabyte GA-AB350M Gaming 3 Palit GT-430 Corsair Vengeance LPX CMK16GX4M2B3000C15 
Hard DriveCoolingOSMonitor
Samsung 850 EVO AMD Wraith Spire Linux Mint 18.x Dell UltraSharp U2414H 
KeyboardPowerCaseMouse
Dell SK-8185 Thermaltake ToughPower 850W Lian-Li PC-A04B Logitech Trackman Wheel 
  hide details  
Reply
Ryzen
(12 items)
 
  
CPUMotherboardGraphicsRAM
Ryzen 7 1700 Gigabyte GA-AB350M Gaming 3 Palit GT-430 Corsair Vengeance LPX CMK16GX4M2B3000C15 
Hard DriveCoolingOSMonitor
Samsung 850 EVO AMD Wraith Spire Linux Mint 18.x Dell UltraSharp U2414H 
KeyboardPowerCaseMouse
Dell SK-8185 Thermaltake ToughPower 850W Lian-Li PC-A04B Logitech Trackman Wheel 
  hide details  
Reply
post #14 of 30
Quote:
Originally Posted by parityboy View Post
I'm no expert but I might have to disagree with you there. It sounds a bit like, "remote desktops have no place in the X server...".

I understand what your saying, but I would have thought that latency would play an issue if you introduce another entity. I would envision a modular architecture where the audio server has some kind of auto-discovery of other servers on the LAN, and treats them as another piece of audio hardware.

I'm not saying network audio is needed at all, but it would be a nice feature; Apple do some killer things with it.




This is how you design a low latency audio subsystem. Funny thing, the answer has been sitting in books for years ! I have a Tascam SX-1 powered with BeOS software, and its amazing for a nearly 10 year old machine.

http://www.haiku-os.org/legacy-docs/..._Overview.html
post #15 of 30
Quote:
Originally Posted by parityboy View Post
I'm no expert but I might have to disagree with you there. It sounds a bit like, "remote desktops have no place in the X server...".

I understand what your saying, but I would have thought that latency would play an issue if you introduce another entity. I would envision a modular architecture where the audio server has some kind of auto-discovery of other servers on the LAN, and treats them as another piece of audio hardware.

I'm not saying network audio is needed at all, but it would be a nice feature; Apple do some killer things with it.

[edit] Before I get an "it has it's own audio drivers"

Code:
YMF754
SoundBlaster
Trident DX/NX, SiS7018, ALi 5451
Prodif24
ES1879
Pinnacle and Fiji
AC97 support (specific Intel/Nvidia/SiS, Unknown)
ICE1712
GemTek
That's the state of the "native" haiku sound support, that's pitiful.


You say that, but I can't get Xine to work with DVDs at all. Most of my DVDs are ISO files, and even mounting them via /dev/loop0 and configuring Xine accordingly simply does not work. It used to work when I ran Gentoo...



I was talking about the ALSA->PulseAudio plug-in, not the WINE->PulseAudio plugin. I configure .asoundrc to use the ALSA->PulseAudio plug-in, then tell WINE to use ALSA. The result is choppy audio in WINE.



This may well be the issue, but I simply couldn't get it to work. I'm using Intel HD Audio built into the H55 chipset. Could you paste your .asoundrc as a template for me to follow? I'd appreciate it.
There is no ALSA -> PulseAudio plugin, that's impossible. PulseAudio acts to catch all the ALSA audio streams before they hit dmix/ALSA. It then does it's internal software mixing and passes the sound to ALSA. What your describing would create a loop, there is no way ALSA can output to PulseAudio and then back to itself. Them be paradox waters my friend, it always goes to ALSA last.

So either your program outputs to ALSA or Pulse, either stream gets intercepted by Pulse and mixed. Then Pulse outputs directly to ALSA, as every sound server does. I think your getting this stuff mixed up, because there are no plugins that the sound system uses.

The audio server isn't ment to pick up networked devices and let them use it. I can't think of anything that does that, or any real managable way to do that. In order to use it as an audio device you would have to have a kernel that can do networked drivers/modules. Good luck! Currently what PulseAudio does is broadcast an audio stream similar to the idea behind udpnp, the device picks up the audio stream and manages it itself after that.

Quote:
Originally Posted by SCollins View Post
This is how you design a low latency audio subsystem. Funny thing, the answer has been sitting in books for years ! I have a Tascam SX-1 powered with BeOS software, and its amazing for a nearly 10 year old machine.

http://www.haiku-os.org/legacy-docs/..._Overview.html
Again, we can do that in linux too. All the audio code in that OS is in Linux in the form of? Form of? That's right, OSS4.

[edit]
Before I get a retort about it having native drivers/modules....

Code:
YMF754
SoundBlaster
Trident DX/NX, SiS7018, ALi 5451
Prodif24
ES1879
Pinnacle and Fiji
AC97 support (specific Intel/Nvidia/SiS, Unknown)
ICE1712
GemTek
That's all I could find on "native" haiku support, that's pitiful.

[edit2] https://www.haiku-os.org/tags/audio if it wasn't for OSS4 I'm sure the sound state of Haiku wouldn't be nearly as complete.
Edited by mushroomboy - 10/6/11 at 6:58pm
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
post #16 of 30
Quote:
Originally Posted by mushroomboy View Post



Again, we can do that in linux too. All the audio code in that OS is in Linux in the form of? Form of? That's right, OSS4.

[edit]
Before I get a retort about it having native drivers/modules....

Code:
YMF754
SoundBlaster
Trident DX/NX, SiS7018, ALi 5451
Prodif24
ES1879
Pinnacle and Fiji
AC97 support (specific Intel/Nvidia/SiS, Unknown)
ICE1712
GemTek
That's all I could find on "native" haiku support, that's pitiful.

[edit2] https://www.haiku-os.org/tags/audio if it wasn't for OSS4 I'm sure the sound state of Haiku wouldn't be nearly as complete.

I was specifically referring to the design of the media server,also the media kit. It just works better, period. with some patch's I have made to drivers I can do software monitoring in the 16msec range now. thats FAST.I only had to fix some latency assumptions to do that to. Part of that difference is messaging structure.
post #17 of 30
Quote:
Originally Posted by SCollins View Post
I was specifically referring to the design of the media server,also the media kit. It just works better, period. with some patch's I have made to drivers I can do software monitoring in the 16msec range now. thats FAST.I only had to fix some latency assumptions to do that to. Part of that difference is messaging structure.
I'm sure there are a few people who would back me, you can get lower than that on linux. You can do it with ALSA even if you set it up right with jack. Even so, you don't really notice latency like that so what's the point?

If you want to know numbers, you can get under 12ms latency with ALSA. There are a few here who try. (not me, I used OSS4 to get under 8).
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
post #18 of 30
Quote:
Originally Posted by mushroomboy View Post
I'm sure there are a few people who would back me, you can get lower than that on linux. You can do it with ALSA even if you set it up right with jack. Even so, you don't really notice latency like that so what's the point?

If you want to know numbers, you can get under 12ms latency with ALSA. There are a few here who try. (not me, I used OSS4 to get under 8).


12ms, audio latency ? not gonna happen. Look up DAC rate of coversion. Its on the order of 4-6msec. Now if your talking about outbound only latency, I can get down to 7-9msec on average.

I was talking about round trip latency, input to output. If I send a signal into the mic input I can round trip it back out on software to the output in 16msec range.

Windows ASIO nor Linux can do this. I know, I have tried them both, best I can on widnows with a VERY optimized system on software monitoring, is around 70msec sometimes in the high 60's. that pretty respectable. I was never able to get it working with linux and ardour or jack because the driver was to unstable. I could try again however. I doubt the results will change.

Now if we take advantage of hardware monitoring, its all on the card.

I still contend, that the BeOS audio subsystem is one of the best all around designs and no one has improved upon it. If linux developers would losee the, not invented by us attitude, linux audio and graphics wouldn't be as bad as they are.
post #19 of 30
Quote:
Originally Posted by SCollins View Post
12ms, audio latency ? not gonna happen. Look up DAC rate of coversion. Its on the order of 4-6msec. Now if your talking about outbound only latency, I can get down to 7-9msec on average.

I was talking about round trip latency, input to output. If I send a signal into the mic input I can round trip it back out on software to the output in 16msec range.

Windows ASIO nor Linux can do this. I know, I have tried them both, best I can on widnows with a VERY optimized system on software monitoring, is around 70msec sometimes in the high 60's. that pretty respectable. I was never able to get it working with linux and ardour or jack because the driver was to unstable. I could try again however. I doubt the results will change.

Now if we take advantage of hardware monitoring, its all on the card.

I still contend, that the BeOS audio subsystem is one of the best all around designs and no one has improved upon it. If linux developers would losee the, not invented by us attitude, linux audio and graphics wouldn't be as bad as they are.
https://help.ubuntu.com/community/Ho...KConfiguration
old.nabble.com/Intel-hda-jack-low-latency-howto-td20291253.html

I have reached ms on Windows that is extremely low. Not to mention DJs have gotten latencies on Windows that is very respectable, how do you think Traktor works? You get the high end audio equipment and you get extremely low latency. I know Linux doesn't do that, the only OS that rivals that (and gets lower) is OSX. I'm huge into latency and can tell you that you can't beat OSS4... Mainly it's the same in linux as it is in the other OS.

Trust me, what you have is good but Linux can perform equally.

[edit] What initially fueled my desire to find low latency sounds was DJ mixers. I then quickly found out Linux had no means to address the actual midi outputs. I was still able to achieve acceptable latencies for DJs. Linux CAN do that, if you really try. The problem is it doesn't off the bat, though in all honesty who needs that? The only reason you need low latency is if you are trying to do audio ques and match them to something. Other than that you have no need to know how quick your audio gets to your speakers (applications or what not). You hear sound at X intervals, it all starts and stops at the same latency and you don't know the difference. Just acknowledge that you don't know (or hear) the difference between those latencies. If you think you can, I'm certain I can play music that would make you double think that.
Edited by mushroomboy - 10/7/11 at 10:06pm
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
Current Rig
(14 items)
 
  
CPUMotherboardGraphicsRAM
FX-8350 4.6GHz@1.44v GA-990FXA-UD3 R4.0 HD 7950 (1100/1450) 8G Muskin DDR3 1866@8CLS 
Hard DriveOptical DriveOSMonitor
1TB WD LiteOn DVD-RW DL Linux/Windows 19" Phillips TV 1080p 
PowerCaseMouseMouse Pad
OCZ 600W Generic Junk Logitech MX400 Generic Junk 
Audio
SBL 5.1 
  hide details  
Reply
post #20 of 30
Quote:
Originally Posted by mushroomboy View Post
https://help.ubuntu.com/community/Ho...KConfiguration
old.nabble.com/Intel-hda-jack-low-latency-howto-td20291253.html

I have reached ms on Windows that is extremely low. Not to mention DJs have gotten latencies on Windows that is very respectable, how do you think Traktor works? You get the high end audio equipment and you get extremely low latency. I know Linux doesn't do that, the only OS that rivals that (and gets lower) is OSX. I'm huge into latency and can tell you that you can't beat OSS4... Mainly it's the same in linux as it is in the other OS.

Trust me, what you have is good but Linux can perform equally.

[edit] What initially fueled my desire to find low latency sounds was DJ mixers. I then quickly found out Linux had no means to address the actual midi outputs. I was still able to achieve acceptable latencies for DJs. Linux CAN do that, if you really try. The problem is it doesn't off the bat, though in all honesty who needs that? The only reason you need low latency is if you are trying to do audio ques and match them to something. Other than that you have no need to know how quick your audio gets to your speakers (applications or what not). You hear sound at X intervals, it all starts and stops at the same latency and you don't know the difference. Just acknowledge that you don't know (or hear) the difference between those latencies. If you think you can, I'm certain I can play music that would make you double think that.

Hook a scope up and a signal generator, start measuring your latency's. They are FAR longer then they are claimed to be.

Your issues with midi, to performance, I ain't gonna touch that one, but your talking about 2 entirely different systems that are communicating across multiple nodes and conversion. Midi performance is in the 30-50msec range at best. That doesn't include outbound. fairly typical pc rig midi latency's when actually measured from source command to sound output, border on the average of 100-150msec.

Once your outside of general audio streaming and into audio generation, you OS scheduling plays a huge part in how the system responds.

Let me tell you this, OSX claim on latency are flat wrong. The only way to get OSX to move that fast, is to use dedicated cards with dedicated audio processing etc in the cards. Avid make these devices for protools, turns the pc into a glorified mixer.
New Posts  All Forums:Forum Nav:
  Return Home
  Back to Forum: Linux, Unix
Overclock.net › Forums › Software, Programming and Coding › Operating Systems › Linux, Unix › The State Of Linux Audio