Shuttleworth for sure doesn't have a focus on audio and multimedia. Otherwise he wouldn't put Banshee or similar useless stuff in the package.
I'm sure he hasn't even understood the problems associated to audio.
Weired attitude.
Let's face it. Nobody who is supplying todays serious audio interfaces is providing
Linux drivers. And if there are drivers they are available five years after product launch and stripped down to some very basic features. And that situation is getting worse.
OSX is a UNIX. It should be possible.
I am not talking about distributors but about people working on the core technologies. I do not know anyone from ubuntu playing a major role in alsa/alsa-lib. Novell, RedHat, SoC manufacturers.
Unix has nothing to do with kernel internal structures, but about APIs (POSIX etc.). Linux drivers use linux kernel submodules, just as BSD (i.e. OSX) drivers do. I cannot imagine how you could write a portability layer to emulate these very internal features. Perhaps in user space with very poor performance.
I personally see the situation in audio drivers as improving. Many manufacturers are focusing on usb audio 2.0, supported in linux, the cheapest PCI-e intefaces are often supported, semi-pro mostly supported (asus), professional - some are, some never will (Lynx). Just as you cannot find windows 7 drivers e.g. for Audiotrak Prodigy192 AUDIOTRAK Community forums • View topic - Audiotrak Prodigy 192 + Windows 7 x86 Now let's talk about poor HW support. Or better not, waste of time anyways.
well, what perhaps may be done (to a great avail for everyone) would be to create standardized, OS-independent "driver interfaces" (something like "NDIS") at least for the most common type of HW interfaces (e.g. video, audio & network cards, printers, modems, ecc).
That way hardware manufacturers would need to develop, maintain and distribute only one universal driver (or at least one for each supported hardware platform) which could then be used on any OS supporting the standard driver interface.
Unfortunately, even assuming that this may be technically doable (which is not obvious), I'm afraid that it will never be accepted by prominent commercial OS vendors such as Micro$oft. Which leverage hardware support (driver availability) to keep their almost-monopolist market dominance...
Certainly, it would be a nice way to go. Though I share your doubts about real-world chances.
But it would still require having new drivers written to this new specification, not using the existing OSX drivers.
of course... (though likely that would not be a problem if the most widespread OSs would embrace/enforce the standard). Anyway, these are just useless speculations. We have to live with what we do have, not with what we may like to have. Bottom line is, if you don't like ALSA get your hands on and try to make it better if you can.
Hi folks.
I just discovered Clementine (0.7.1). A player base on Amarok 1.4. ported to Gnome.
It's a cross-platform player also ported to other OSes.
It comes with songinfo, lyrics, coverart manager, tag manager asf.
You can handle output devices more flexible with Clementine.
I got it running with pulseaudio now. As Amarok, Clementine keeps running in the background if you close the main-window.
You'll be notified on track changes with on on-screen notifications.
The overall feature set it is not state of the art yet. E.g. I'd like to see the cover manager integrated into the main window, reflecting the library to choose
the albums from.
However, I do think Clementine can compete with other Gnome based players quite well already now.
For now it made my desktop system running NattyNarwhal look complete.
I kind of like it. Integrates well into Gnome/Unity. Also works with the Gnome-Panel sound controls.
It'll stay.
Get the latest builds:
Cheers
I just discovered Clementine (0.7.1). A player base on Amarok 1.4. ported to Gnome.
It's a cross-platform player also ported to other OSes.
It comes with songinfo, lyrics, coverart manager, tag manager asf.
You can handle output devices more flexible with Clementine.
I got it running with pulseaudio now. As Amarok, Clementine keeps running in the background if you close the main-window.
You'll be notified on track changes with on on-screen notifications.
The overall feature set it is not state of the art yet. E.g. I'd like to see the cover manager integrated into the main window, reflecting the library to choose
the albums from.
However, I do think Clementine can compete with other Gnome based players quite well already now.
For now it made my desktop system running NattyNarwhal look complete.
I kind of like it. Integrates well into Gnome/Unity. Also works with the Gnome-Panel sound controls.
It'll stay.
Get the latest builds:
Code:
sudo add-apt-repository ppa:me-davidsansome/clementine
sudo apt-get update
sudo apt-get install clementineCheers
Last edited:
I still think that for hifi use the best one is Deadbeef... simple and effective!
Best
Pietro
Best
Pietro
This depends on formats supported by the card. E.g. Envy24 cards accept only S32_LE, older cards only S16_LE. Yet the player can support 16 - 32 bits.
If your are using ALSA drivers, you can look at:
/proc/asound/card0/pcm0p/sub0/hw_params
While playing an audio file and you can see format, rate and bits. Substitute 'card0' with your soundcard ID.
Footnote for this, if you aren't routing directly to hardware with alsa but use say pulseaudio, then this isn't useful since pulseaudio always outputs the number of bits specified by the sampling format in daemon.conf.
( /etc/pulse/daemon.conf or in userspace: ~/.pulse/daemon.conf )
So if you use pulseaudio, make sure you enter the right sampling format into that file, and when you're at it you can set sampling rate and upgrade your resampling alogorithm =)
// Olle
( /etc/pulse/daemon.conf or in userspace: ~/.pulse/daemon.conf )
So if you use pulseaudio, make sure you enter the right sampling format into that file, and when you're at it you can set sampling rate and upgrade your resampling alogorithm =)
// Olle
What's Pulse's default ? 44.1/16 ? I'm just wondering if I need to do anything to tweak my setup ? I have 44.1/16 flac files playing through Rhythmbox in a standard Ubuntu 10.10 desktop installation and using an Envy24 soundcard - an Onkyo se-200pci.
Thanks !
Yes, as far as I know that is the default.
The resampling algorithm used isn't astronomically good, but isn't as bad as it was in the beginning of pulseaudio in ubuntu where it was awful.
If you only play 16 bit audio then it's whatever, but since you probably don't it wouldn't hurt to fix the sampling format. Of what I found when searching the Envy24 is a 24-bit sound card, so should be able to receive atleast 24-bit, possibly 32-bit format.
Many 24-bit sound cards cannot receive 24-bit sound with s24le but instead wants 32-bit with s32le but ignore the foremost bits. My card Asus D2X for example does this. But enough of fluff and back to helping you =)
Even if you know this lots probably don't so I'm going to explain this from the beginning:
You create a text file named daemon.conf in ~/.pulse/ (~ is your home folder, so for me ~/ is equal to /home/olle/ )
if the folder .pulse doesn't exist you create it, but it should exist already. It is hidden though (the . in front) so if your using nautilus you can press CTRL+H to make it visible.
Now create the file daemon.conf
You can take the original file from /etc/pulse/daemon.conf and just copy the text and paste, it works so that if a line with say sampling format exists in the local file in your home folder it uses that, and if it isn't there it uses the sampling format in the /etc/pulse/daemon.conf file.
So in your case you can test to enter "default-sample-format = s24le" into the file on a line and that should be it.
( If you say want to change the resampling algorithm you just have to add another line with say "resample-method = src-sinc-medium-quality" )
Now kill pulseaudio with for example "pulseaudio -k" in the terminal for it to restart and test to play some audio. If it doesn't work, you can test to change sampling format to "default-sample-format = s32le" and test again.
When it's playing you can verify the bit depth by using cat /proc/asound/card[X]/pcm[Y]p/sub0/hw_params and check output.
If it plays 24 or 32-bit then it works, yay!
EDIT: since an example says more than many words I've included my daemon.conf as an example. daemon.conf - Pastebin.com
Last edited:
Thanks ! I never would have worked that out for myself ! ;-) I'll try this tomorrow.
My experience with Windows makes me think any resampling algorithm is bad news. Is this the same with Ubuntu ? I thought Linux didn't resample ? Does it just change the word length and not the sampling frequency ?
Thanks for the help - very much appreciated !
My experience with Windows makes me think any resampling algorithm is bad news. Is this the same with Ubuntu ? I thought Linux didn't resample ? Does it just change the word length and not the sampling frequency ?
Thanks for the help - very much appreciated !
OllBoll, I will repeat the third time Because of this:
the following does not work:
You will always see S32le, no matter what the player uses internally. If the last element in user space sends a different format to these cards drivers, they refuse with the "Unsupported format" error. One case is the player consults the driver about supported formats and adjusts accordingly before sending the samples to alsa user-space API (libasound, alsa-lib), just as e.g. mplayer and probably pulseaudio do. For the rest of the players (e.g. sox, aplay) your alsa card definition configured in the player must include the plug plugin (plug:hw:ICE1724).
For these single-format cards it is generally impossible to find out the actual player internal format from the outside, unless the player reports this information or someone consults its source code.
Because of this:the following does not work:
When it's playing you can verify the bit depth by using cat /proc/asound/card[X]/pcm[Y]p/sub0/hw_params and check output.
If it plays 24 or 32-bit then it works, yay!
You will always see S32le, no matter what the player uses internally. If the last element in user space sends a different format to these cards drivers, they refuse with the "Unsupported format" error. One case is the player consults the driver about supported formats and adjusts accordingly before sending the samples to alsa user-space API (libasound, alsa-lib), just as e.g. mplayer and probably pulseaudio do. For the rest of the players (e.g. sox, aplay) your alsa card definition configured in the player must include the plug plugin (plug:hw:ICE1724).
For these single-format cards it is generally impossible to find out the actual player internal format from the outside, unless the player reports this information or someone consults its source code.
It all depends on your applications and alsa chain configuration. If your system supports playing multiple streams at the same time, it must resample to common frequency. Therefore, if your system is using pulseaudio (any modern desktop distribution in default configuration) or alsa plugin dmix (the "default" device as defined by alsa packages), it is resampling. If you tell your playback applications to output directly to device "plug:hw:YOURCARDNAME", no resampling occurs for sampling rates supported by your card. But only a single stream can be played (all other concurrent attempts end up with "device busy" error) which is unacceptable for general use desktop.
It is all in your hands
- Status
- This old topic is closed. If you want to reopen this topic, contact a moderator using the "Report Post" button.