The dirty secret in software development: most think they how to write efficient software when they need to, but very few can.
Sometimes the excuse is that cpu and memory are cheap as if resources aren't under constant pressure from the hundreds of processes that all pretend they are the only one on the machine.
Many also don't know how to draw simple, low-overhead abstraction boundaries. Everybody wants to make the most generic code planning for things that will never happen or at least not in the way they think. You can't call out most people on this because this one piece of code they are working on is always the exception.
And most developers don't know how to optimize as they write code. They often don't understand the problem or have enough mechanical sympathy to understand what code you should probably be careful with and should be made quick to start off with. They probably don't understand the cache system enough to know why that linked hash table is probably the wrong data structure. Hash means fast to them, and to them this is all premature optimization even when the correct solution is probably no more difficult than what they are doing. Calling something premature optimization is often used to shut down discussion of how their code can be improved.
The field is too in love with horribly inefficient frameworks. Writing network code and protocols is now considered too low level for people. Many are too caught up it what is tech-cool. They're like the holistic medicine practitioners of software and they don't even know it.
If you ask developers to write efficient code and give them the means to do it, they will write efficient code.
But unless they work in embedded software, this is rarely a priority. In fact, this tends to be actively discouraged : in the good shops, reliability, robustness and security is the goal, in bad shops, that's bullet-point features and meeting unrealistic deadlines.
To get an idea of how optimization is poorly regarded, look no further than the infamous Heartbleed exploit of OpenSSL. One of the contributing factor for this bug was that the team used a custom memory allocator for performance reasons. After the bug was discovered, the team was actually blamed for it more than anything else that lead to the bug. And FYI, it was a real performance improvement, at least on some platforms.
You seem to be under the impression that writing efficient code is at odds with writing reliable or robust code. Efficient does not mean unsafe. Efficient code does not have to shoot-from-the-hip. Efficiency means that the task is completed with the minimum wasted effort. To assume that you cannot have relieable code that is also efficient is absurd.
If reliability is the top priority for your project, it just means you factor that in to your optimizations. It doesn't mean you just ignore efficiency and write any old shit, as seems to be the custom today.
Your OpenSSL example seems to suggest the Heartbleed exploit was a result of developers daring to write performant code, and not that they simply wrote buggy or insecure code, performant or not.
I feel the problem here is what I imagine as this formula:
reliability * efficiency = developer skill
I.e. for a given level of reliability, you need more skilled[0] developers to be able to write efficient code. And I'm not thinking about premature optimizations here - just that the code an experienced developer will write the first time around will be efficient enough.
So in short, if you aim for certain level of reliability and employ cheap/unskilled developers, efficiency will suffer. And as long as companies don't really care about performance, developers will not gain the necessary experience to write efficient code with just-in-time optimizations.
--
[0] - for "skilled" meaning probably mostly some knowledge and experience in writing fast code; it's probably not the experience you'll get when all coding you've ever done is for the web.
I think he's referring to the pressures to produce working solutions. And there's a whole laundry list of attributes people attach to that process. And everyone has the opinion that they're ideals represent the best/most important subset of all the possibilities and/or that you should just meet them all or go work at McDonalds.
You can certainly write efficient code, that's reliable and robust and secure given the time and resources to do so. It usually comes down to money, and how no matter how efficient or high minded you are, crafting the optimal solution takes more time and resources. IE more money. If you can sell users and clients on the extra costs, great. Otherwise you need to figure out what you can do, with the time and resources you have, that will sufficiently satisfy your customers.
And yeah, the problem is with the gobs of resources available on modern computers writing efficient code matters less because most users aren't going to care if their music player is using 1% of the CPU or 10% of the CPU.
Of course I say that with the annoying exception I've experienced where the custom MP3 player in GTA V requires a relatively huge amount of resources and will easily reduce performance by 10-20FPS even on an overclocked i5.
>You seem to be under the impression that writing efficient code is at odds with writing reliable or robust code.
For a given amount of resources invested it is. From a business perspective this includes not just the time a developer spends on a given piece of code, but how good a developer one is willing to pay to work on the code. Perhaps those making the business decisions overestimate the cost of writing more efficient code and underestimate the costs of not writing more efficient code, but they there is a cost that will be taken into account.
>To assume that you cannot have relieable code that is also efficient is absurd.
Of course you can, but often it takes more time (or more expensive developers) than inefficient code, and the people paying the bill don't necessarily benefit from the efficiency.
I want to believe this. Evidence shows that people tend to grow their problem so that they are attempting to solve the problem of writing software with every other developer. Hence the rise of frameworks.
Sometimes, people get a knock out and do a good job. Bootstrap was seen that way for a while. (I've not heard much of it lately, so assuming it has waned in popularity?) By and large though, we all have different requirements for development. And none of them are shared by the customers/users of our software.
There's also this weird collectivist thing going on with software development, where not using frameworks is looked down upon. Or rather, frameworks are considered a best practice without taking project requirements into consideration. Sometimes, said developers then blog about how they used a nailgun to swat a fly, and the hype cycle continues.
Example: everybody wants their web pages to be smaller but nobody wants to part with massive JS frameworks for sites that everyone are using, even if their site is mostly text. Instead, endless amounts of blogging and engineering time are dumped into things like minification, compiler tech, and other esoterica to solve a problem created by developers. This is incidental complexity, and it lays waste to software systems.
In short, the zeitgeist selects what it wants to hear.
In my observation, this puts the blame in the wrong place. It's simply that most software development is feature-driven, and efficiency is rarely held to be a feature by the business that's paying for them. That is, until it becomes a problem, at which point there are enough low-hanging fruit left by the constant scramble for user-facing shiny that making it not a problem again is relatively straightforward.
I didn't buy that excuse at all. Devs have a habitual problem blaming others for their poor code.
Often better code takes only marginally longer or even less time since you aren't having to deal with all the extra complexity that tends to be a part of "modern" development.
The complexity is of our own making. We spend too much time on this extra cool and extensible way to use json and xml in case we even want to run on a quantum computer in in 50 years or avoid a simple recompilation when we need to change a constant that will likely never need to be changed when we should have been spending that time on more important things.
You're conflating "better" with "more efficient to execute." That's only one possible interpretation of "better", and it's usually not the most important one.
but it very often is. If you're a web developer, for example, little matters more to your users than performance. This has been demonstrated an almost infinite number of times by now, but surprisingly few industry professionals seem to pay any attention to it
Yes, and we can point that out to our business owners until we're blue in the face, but until they see the benefit they won't pay us to do that work. It can be surprisingly difficult to get this point across.
Just because something matters objectively, doesn't mean it matters to the client/business (at the moment). And unless you as the developer are in the position to dictate that, sometimes you're at the mercy of non-technical requirements or demands. You can be right about everything, but unless you're the boss, at least sometimes you can only do what you're told.
And that the software is available (ie actually shipped). And to use it they need to know it exists and what it's for, which usually involves some marketing.
I think it unfortunately takes experience to write efficient code the first time around. Experience people are not gaining, since there is little to no focus on performance outside embedded and gamedev circles.
Well for some reason it's those people [1] who have the money so they call the shots.
Do you know of organizations where an internal drive for excellence is cultivated? Where technical people communicate directly across hierarchy levels and horizontally? Maybe even outside the company?
[1]: People who are relatively close to the customer and not the implementation. Those people don't tend to understand how efficient some things are because they can't estimate how long something should take from lower principles which they have a benchmark for.
This makes them much happier software users.
"Sometimes the excuse is that cpu and memory are cheap as if resources aren't under constant pressure from the hundreds of processes that all pretend they are the only one on the machine."
Does anyone know if there's a generalized name for this problem? It's the same one where your teacher gives you "only two hours of homework tonight" but forgets you have four other classes all doing the same thing.
Tragedy of the Commons, as mentioned by others, sounds most adequate. In general this is one of the whole class of coordination problems - where actors reach globally suboptimal outcomes by failing to coordinate with one another.
Tragedy of the Commons seems to imply some harm is happening to the actors themselves; the coordination problem with computing resources here is a little different, because most of the time, application vendors don't feel any impact of the problem they contribute to, which makes them even less incentivized to coordinate.
"Originally, Parkinson's law is the adage that "work expands so as to fill the time available for its completion", and the title of a book which made it well-known. However, in current understanding, Parkinson's law is a reference to the self-satisfying uncontrolled growth of the bureaucratic apparatus in an organization."
Hmm, I can see how they're related, but it doesn't seem to be quite what I'm talking about. I'm more referring to the overuse of resources by individual elements assuming or acting as if they're the only thing using it, like in the above examples of a teacher acting like their class is your only one, or a thread consuming resources like no others are active.
Parkinson's law more seems to be the result of the effect that I'm talking about (among others, like procrastination).
A simple thing is to figure out if you can restrict the runtime environment during development (available memory, clock speed, network speed, etc), and develop to that. The nice side effect is there's more of your computer available for IDE's and browser tabs.
Secondly, abstraction doesn't necessarily track with efficiency/inefficiency.
Efficient programming is all about knowing how to use CPU features and memory to your advantage. If you don't already know C, I suggest "Learn C the Hard Way"[0]. After that, here's two great places to start: "What Every Programmer Should Know About Memory"[1] and "What's new in CPUs since the 80s and how does it affect programmers?"[2]
Go learn yourself some embedded, if you want to deal with extreme resource constraints, or some gamedev, if you want to know how to write performant code with enough tasty high-level architecture decisions to satisfy your abstraction needs.
"Arduino" and other small-system programming. Or get an emulator and try to write an Atari 2600 game: you have 128 bytes of RAM, don't use it all at once.
It's not a complex. I'm always very surprised by this attitude. Theory serves practice.
Case and point: the OP mentions that an understanding of cache architecture enables you to reason about which data-structures exhibit good cache locality. Discovering that hashtables have poor cache locality by trial-and-error seems like a waste of time compared to gaining theoretical insights.
I'll second "Racing the Beam", although it's a history rather than a theoretical approach.
I think you may have hit a linguistic snag here; there's lots of "theory" in the classical CS sense dealing with performance from an O(n) point of view, such as Knuth's work. But for producing fast results on actual hardware you end up having to take into account lots of ugly details of the platform. Learning about cache behaviour doesn't really fit into CS so it's not the first thing people think of when you ask for theory.
"Knowledge transmitted by practitioners through written and oral culture outside of the academy": what's the word for this?
Part of the problem is that some of this stuff has a pretty short shelf life. There's a lot of optimization knowledge that was useful at one time but is now flat out wrong.
Oral culture is especially prone to this -- at least a blog post or a physical book has a date on it. You have no idea when the your co-worker's suggested optimization technique was developed.
I think 'theory' is just fine, you can't fix all communication failures by throwing moar words at it. At some point you have to make peace with the fact that not everybody uses words the same way you do.
I think there's a miscommunication here. By "write some efficient code" GP presumably meant the "pull" approach, in which you identify the code that's causing you performance problems and then try to make it faster, learning everything you need on the way. Rinse and repeat. It's a very efficient way to learn, and also good at teaching you those intutions that are hard to put down in writing.
That said, if anyone knows some kind of collected guide to writing efficient software, I'd be happy to learn about it, 'cause I haven't seen anything like this published.
I am like you. Every big performance win i ever got was from changing algorithms. Sometimes i didn't write either the old or the new, but just swapped out a different implementation. A good handle on that stuff can get you a long way. And can certainly be picked up from reading. it's a lot closer to just math.
That said, spend a week with C and valgrind/cachegrind. There's a lot of theoretical stuff that is hard to get at (or is for me) without a little exposure to how the system works. a coupe hours here and there will extend your mental model to include the various layers of cache. That'll make the more esoteric stuff more accessible.
I think Peter Norvig's article 'Teach Yourself Programming in Ten Years' [0], might be useful to you. One of his points is to 'Remember that there is a "computer" in "computer science"', along with examples of things to investigate.
Efficiency can be done but it requires disciplines only taught in courses on real-time and embedded programming, and those seem to be fairly rare these days. Real-time and embedded programming teach the programmer how to reason about finite resources like time, energy, memory, and floating-point operations while requiring a level of mastery "down to the metal" that's also rare in overly abstraction-driven programming. RTE skills make every programmer better in the same way that glider skills make every pilot better.
I went to Cal and aside from some hardware classes i never had a real time or embedded class.
I think it requires an open mind to want to learn these things and put effort into it instead of blowing things off as premature or something the maintainer of the code behind you will come and fix.
Anecdotal but this matches my experience. I went to generic public school for ocean engineering and took tons of embedded classes. I then worked on a student robot project and was shocked when the CS students were completely lost with how to approach writing drivers and interfaces for the sensors and such. I thought that would be standard for CS.
> CS students were completely lost with how to approach writing drivers and interfaces for the sensors and such. I thought that would be standard for CS.
No, that would be standard for computer engineering, not CS.
Try to have a conversation about hardware to many practicing software developers who were CS majors and they'll look at you as if you've grown a second head.
I mostly agree, but I think you're too quick to assume that everyone who doesn't write optimal code is doing so because of some tech fad. Frequently it simply doesn't pay to write optimal code; there's no viable business case. Sure, using an array can be faster and not much harder than using a hash table, but writing a network protocol is frequently not worth the effort. In my experience, poor performance comes from the inability to make a business case (whether or not one actually exists), not from chasing fads.
I think good programmers, by default, try to write readable, easy-to-maintain code. If you ask them to write high-performance code then they will do it, knowing that readability might suffer because of it.
"Sometimes the excuse is that cpu and memory are cheap as if resources aren't under constant pressure from the hundreds of processes that all pretend they are the only one on the machine."
I find that this often extends beyond performance too. Many websites/apps waste lots of screen space because they were clearly designed for, and tested at, 1080p.
I think the secret is slightly different. Most think they can fully solve a problem. Such that their solution is the one everyone should use.
This manifests in assuming everyone can afford the abstraction boundaries chosen. Or that everyone needs the same tradeoffs. Or, ultimately, that everyone would come to the same conclusion.
I think of it as the desire of most people to boil software down to formulaic choices. Imagine if you came up with something as elegant as "F = ma" for software.
I feel this is somewhat related to the rise in functional programming. It is not that either of those things are bad goals to chase. But they are not ends to themselves.
>The field is too in love with horribly inefficient frameworks. Writing network code and protocols is now considered too low level for people. Many are too caught up it what is tech-cool. They're like the holistic medicine practitioners of software and they don't even know it.
While the frameworks themselves are made for a particular purpose, they are often misused. One great example would be electron. I found an electron clone of Keepass. Now why would anybody want that.
And you find people justifying Huge bloated electron apps that take a minimum of 50 MB for a simple Hello World. And then they say memory is cheap.
I say memory is cheap for 1 app at that size. Not running all apps at that size. If busybox can run GNU coreutils with a size less an MB then why can't they make more efficient apps?
If you're not developing for a real-time system, like most (all?) larger games or software for embedded hardware, it is likely that you are not thinking about performance very much, even if you have the time and skill to do so.
You don't think about performance, as a developer, usually, until it becomes a problem, and there are so many layers and frameworks between an MP3 player and the CPU that this kind of thing should be expected.
It is much more difficult to keep a real-time system working in real-time than it is to keep something performing as well as a desktop computer user expects it to perform.
I wish I could take credit, but i think it was Martin Thompson that coined the phrase. I think it if a perfect deception of the, often subconscious, understanding of what is going on underneath the code.
You can get dedicated MP3 low-power decoder chips. You might have one in a fancy PC soundcard (SBLive?), but I don't think it's included in baseline AC97.
(I remember having a 486DX that could decode MP3s with the Fraunhofer player at about 95% CPU but not Winamp, which was slighly too slow to keep up)
I don't know exactly; the chipsets tend to be closed. I've seen baseband processors which have the AMR codec in hardware (adaptive multi-rate, used for GSM phone audio).
Ditto for foobar, it's complete but not obnoxious and tends to focus on what's important. It's probably the one thing I miss when using my (OSX) laptop, OSX players seem to be either obnoxiously turdy (à la itunes) or exercises in minimalist style which end up inconvenient to use.
I don't know how CPU-efficient it really is though, and that seems to be Ted's main concern.
My only annoyance with it is that (AFAIK) there still isn't a 64b version of it, though that problem is so common on windows it's hardly worth mentioning.
It had a similar spirit to Winamp, so much that AOL/Nullsoft looked into acquiring them. As did Apple before iTunes existed, as documented in The True Story Of Audion:
I liked using VOX for some time because of its FLAC and BS2B support, but dropped it because of iTunes Match and Apple Music convenience. Now I see they introduced a FLAC digital locker too, but the price is steep.
> I don't know how CPU-efficient it really is though, and that seems to be Ted's main concern.
It's ancient software pretty much, written to be efficient on computers several generations back; should be fine as long as it hasn't had any major rewrites since then.
I recall using foobar2000 after becoming disgruntled with the UI bloat of Windows XP's builtin Media Player circa 2003, and it was already lean back then, so I don't have any worries that it will be fat now.
It is probably about as close to ideal as one can get on Windows. The codecs themselves are of course implementations that have been reasonably optimized and at the end of the day the audio framework in Windows is the limiting reagent for further power efficiency gains.
Same for me when I was moving to Linux; missing a music player as good as foobar2000 kept me from changing for quite some time. In the end I settled with Clementine which is pretty good, but my music listening actually decreased quite a bit because of the change, strange as it may sound.
Not nearly as customizable as Foobar, but in case you're wondering if there's something better than iTunes, then Swinsian is a fantastic alternative macOS music player: http://swinsian.com/
The way to go with foobar is to download a premade UI you like. Sometimes the installation process is a little convoluted, but nothing compared to customizing its UI yourself from scratch. Back when I used foobar a lot, my go-to UI artist was br3tt on DeviantArt, I don't know if he's still active.
Nowadays I listen to music off my phone, and on that platform BlackPlayer is as close to perfect as a music player gets.
I'm surprised not to see any mention of Clementine (https://www.clementine-player.org/) here. I switched over to it last year and it's lovely. The interface is nothing special but it's quick and efficient, and the library updates are immediate (I assume it uses libnotify/equivalents). On Windows it idles at 70MB of RAM and 0.2% CPU whilst playing FLAC files for me. Similar stats on my Linux laptop too, from what I remember. Great audio codec support and it has various features for cloud streaming services, though I don't use those.
I'd recommend trying it out, I think you'll be surprised by how nice it is to use.
It still has buffer hiccups when playing off a networked drive (apparently an old gstreamer issue), doesn't support LADSPA plugins (which probably isn't too relevant for an efficiency goal), and you have to add podcast files from their folder to be able to rate them, but all in all it does feel like good old Amarok 1.x.
OSX battery usage is nowhere near as nice - it's very CPU intensive unfortunately. I enjoy the software itself (even though I can repeatably crash it when trying to set up some of the cloud music providers), but the power drain on the battery means I rarely use it when not on AC power.
There is something seriously wrong with Clementine on osx, which is unfortunate. Ui consumes tremendous CPU and is laggy as hell. This is a known, reported issue but has not been fixed. It is a shame also because there isn't a decent lightweight player for Mac even close to foobar. Foobar on Mac works well but audio in wine is a mess.
On Windows, AIMP 3 is king. Especially for those of us who are nostalgic about Winamp 2.95 which was for many years the best simplistic music player that got the job done and got out of the way.
AIMP 3 takes 30MB of RAM even with 20+ GB playlist, on a machine with two sound cards, playing music 10-12h a day, and I've never seen it going even above 2% of CPU.
That being said, the author's sarcastic tone is fully justified. Everybody picks a favorite language and defends it, as if it is their parents under fire. I am all for Elixir and I love it, but I already had to write Golang several times because I needed more raw speed, being one example.
Don't be fanboys, fellow programmers. You're paid to do jobs, not being cool. Too many forget that.
That it contains more than 20 GB of song data? If so, I fail to see how that relates to the memory needed to talk about the songs.
If it's instead 20 GB of actual song meta information, then I'm both and impressed by and a bit scared of your music collection. :) And also impressed by the software's ability to deal.
The actual amount of data in that 20GB that needs to be handled by the player for that playlist is probably on the order of a few bytes bytes per MB. If we round up to 100 bytes per MB, you're still only looking at a few MB of metadata.
AIMP user here. Using it for years. Have it installed on Dropbox. Use same music library on all my systems, and I can pause music on one pc, have it resume on another.
Also many years ago I tested all freely available audio players for there features and lightweight on resources and nothing beats AIMP.
Have years of rating data, play count on the AIMP library system. I wish I could move it to Android somehow.
Anyway that's my quest to find a lightweight audio player.
It's not my favourite language, because I don't program in it myself, but maybe you'd like Pony. It is an actor based language that is actually designed with efficiency and strong static guarantees in mind, with both of these goals informing each other.
Sure thing, I just meant it as a "instead of switching to Go, perhaps Pony as a back-up to Elixir is more of your thing".
Although Pony has new concepts Elixir doesn't have ;)
(Personally, I enjoy watching lecture videos of new languages just for the concepts they introduce me to, even when I never program in them - I can recommmend the CurryOn! youtube channel)
It's just that I want to stabilize my skills and sell myself in new ways recently; thus I am more focused on perfecting what I can do and becoming an expert and a pro.
Lectures introducing new concepts are something extremely valuable!
While everyone else here is proposing to try different players, I liked the idea, found at the end of the article, to certify a program for efficiency. We move our digital life on the mobile and efficiency is quite crucial.
Android can show how much a app / internal program consumes in mW so I wonder if Google is collecting this data in order to classify apps based on this.
Not that I'm a huge fan of it, but Windows 10 (and I think 8) has it under the battery use section in their secondary control panel. It's not quite as accessible, it seems, as macOS' power usage that is readily available in the Finder bar, but it is present.
I'm a big fan of mpd[1]. It's a headless music player you can run on pretty much anything with audio out. You can then control it from a client, of which many are available for nearly any conceivable platform.
MPD runs on 6600 by default, so that shouldn't be a problem. I run it on my homeserver under a separate audio user, who's also in the pulse group to use PulseAudio on the attached speakers.
Everything should be pretty self a explanatory. The "holoscript" part gets executed by my configuration management tool, but it basically means that the two LoadModule lines are appended to the stock /etc/pulse/default.pa
Also, if you have a firewall, open port 6600 to LAN if desired.
Running MPD as a separate user is pretty easy, there's lots of ways to do it and MPD doesn't care as long as it has access to your music and can open the socket (Neither of which require root by themselves). The easiest way is to just modify the user in mpd.conf and let mpd change to the user when it starts. But you can also just start it manually as another user, or change user in the init-script/system-service/etc.. mpd doesn't care how you do it.
PulseAudio on the other hand throws a fit. For reasons unknown to me, PulseAudio basically doesn't support running as a system-wide instance, so things get pretty messy if you want sound to come from multiple users (IE. Your user, and your mpd user). If you only ever use one user on your system, I'd recommend just running mpd under that user - I believe that's what I did to get it working on my computer. Of course, if you're not using PulseAudio then this isn't an issue in the first place.
My understanding is that the preferred way to launch PulseAudio is to launch it as part of your X session so it runs as your user. MPD supports launching in the same way. So done this way, everything runs as your user and therefore plays nicely together.
This is the approach I took, and I think it works very well.
Yeah, you could do that. There's not really much difference between launching it with X and just configuring mpd to run as your user, though launching with X might be easier to setup in some cases.
The only problem with that approach is it means that mpd is tied to your X session. I quit or restart X every once in a while and it's nice to have my music keep going during that time. But obviously that's not a use-case everyone cares about since most people don't have a reason to leave X.
This is the kind of thing where I wonder if a shaming award wouldn't help. Imagine an award, let's say every half year, with a top twenty (one for each of the three big platforms) of needlessly inefficient popular software programs. Ideally with these kinds of breakdowns to back up the claims.
Everyone here is going on about cpu efficiency. When the joke is, that a 10 year old MP3 player can play music all day on a batery the size of a nickle because it's not decoding using a CPU but using a decoder built into an ARM package. The CPU is actually off most of the time when your mp3 player is playing.
The earliest MP3 players required hardware decoders, but it didn't take long for these devices to get faster CPUs that could do the decoding. This in turn enabled firmware updates (either official or unofficial, e.g. rockbox) to bring in support for new audio formats.
An updateable firmware does not necessitate a software decoder. Hardware decoders can (and do) have their own firmware, and can support additional formats if they were designed with that in mind.
Also you can have a hardware decoded MP3 path, and a software decoded OGG path, for example. They can coexist.
Most real hardware wasn't designed to be on the market long enough for any of this to come to pass, though, and you're probably 100% correct.
What? So many mp3 players uses lot more cpu than something like foobar, doesn't matter if that cpu is not used for decoding or not. So, some people uses an lighter player that does the same thing.
I came here simply to mention foobar2000, and I am happy that many people before me did. Some mentioned they missed it on Linux.
I am a Windows user myself, but I feel "ncmpcpp" is
a good alternative on linux (apparently that's an Ncurses Music Player written in CPP). Simple, console list interface with good features.
Audacious[1] set to the classic skin has been my media player of choice for a number of years now since Winamp went crap and I moved away from Windows. It's basically the same as the old Winamp[2], including shortcut keys.
It's simple but works perfectly; I don't understand why music players nowadays are such clunky monstrosities when the music should do all the talking.
It's simple but works perfectly; I don't understand why music players nowadays are such clunky monstrosities when the music should do all the talking.
Same here, I never understood why people were initially so enthousiastic about iTunes or other players after Winamp that tried to hide your audio files behind a convoluted GUI and that abstracted the files on disk into a crappy, opaque database.
For me a directory tree with well-named directories and files is still the least-worst solution and also has been, over time, the most dependable one. (On Android I use Music Folder Player due to this. iPhone I don't know, I don't have one.)
> For me a directory tree with well-named directories and files is still the least-worst solution and also has been, over time, the most dependable one.
This. My Music is very meticulously organized on the file-system level. Every single folder (sans Soundtracks and Videogame music) is organized like so:
My Music -> Artist -> Year - Name -> Track # - Title
e.g.
My Music -> Black Sabbath -> 1971 - Paranoid -> 01 - War Pigs.mp3
That's it. That's all I need. I've had it this way since 1998, and it still works, across myriad computers, file systems, and operating systems. One of the reasons I stayed with Winamp so long is that I could simply right-click on a folder and click "Play in Winamp", and I was all set.
All of these other apps that try to organize my music for me inevitably fail, because the tags are rarely complete or consistent. Trying to backup all my music to Google Play Music has shown that, time and time again.
These days I'm happy that I was finally able to get that functionality back with Audacious.
The problem is that when you use a library-based solution for management, you need to stay on top of tags.
I frequently like to create playlists based on the ID3 genre tag, so a folder-based approach doesn't really work. Folders also complicate things when you're trying to maintain separate music collections -- like a folder for ripped music vs storebought.
> Same here, I never understood why people were initially so enthousiastic about iTunes or other players after Winamp that tried to hide your audio files behind a convoluted GUI and that abstracted the files on disk into a crappy, opaque database.
I still use iTunes. The filing system on-disk is identical to what I was doing anyway.
iTunes Media > Music > Artist > Album > nn Song Name
(Indeed, I point Plex at the same folder and am slowly migrating over to using it rather than the built-in sharing for network playback.)
It's all that extra stuff that can only be done by storing data structures elsewhere: playlists, random by genre, etc, that requires the convoluted GUI and opaque database.
> Same here, I never understood why people were initially so enthousiastic about iTunes or other players after Winamp that tried to hide your audio files behind a convoluted GUI and that abstracted the files on disk into a crappy, opaque database.
A pure hierarchy can't handle compilations or playlists very well. A database, a real one, ought to be the solution - my best player experience was with Amarok 1.x which let you use embedded sqlite or connect to mysql/postgresql.
I don't feel like I want a whole lot from a player, but I do want to queue a track or two while leaving the player on shuffle, to play individual tracks out of a cue/flac, integration with some service that can tell me when a band I like is playing near me, and ideally a recommendations service too. So I've generally ended up with the heavyweight players.
I've been using iTunes since the day it was released 16 years ago, and while the UI has certainly gotten more bloated over the years (seriously Apple split out all the non-music-playing stuff like you've done on iOS already...) I've not once had a problem the dependability.
Even before iTunes was released I used MusicMatch Jukebox. Keeping ID3 tags and file/directory names and syncing things manually with files was always just such a PITA. And how do you even deal with smart playlists or even playlists in general in an efficient way with pure files?
And to the OP's point - it looks like iTunes raises my CPU's power usage from 0.3W at idle to around 0.7W, and that was with the UI visible - keeping my whole machine with display on still at around 5W, or easily powered by a USB phone charger.
The Bongo media player for GNU Emacs works very well with a well ordered file hierarchy. It uses an external backend for playback (mpg321, mplayer, VLC, etc).
It also has a fun feature: a playback item can be an "action", such as stopping playback, or even running arbitrary Lisp code. :)
> On Android I use Music Folder Player due to this
Thanks, installing now. I've had music organised in folders since the mid-90s and it's not correctly tagged. Google Play Music messes up most of it, looking forward to items finally playing in the correct order.
- Spotify is primarily for streaming Spotify songs. It shouldn't be inefficient, of course, but you're looking in the wrong place if you just want to play your audio files.
- Groove: Windows built-in programs are rarely great, why expect otherwise from Groove?
- Come on, dude. You can't just write something off because the homepage has a trendy design. And Shoutcast is ancient technology! I'm pretty sure I used Winamp with Shoutcast on my Pentium 4 and it worked fine.
- Foobar2000 has been around forever! It was fast and efficient ten years ago, and that hasn't changed.
Wonder why you're downvoted. This is entirely true. Bitching about efficiency of music players on Windows without mentioning foobar2000 (which isn't exactly obscure) is pretty fucking silly.
One thing I have noticed about Spotify is it appears to make a lot of requests to various services, some outside of Spotify, if Little Snitch is to be believed.
I suspect the big problem here is not decoding efficiency per se, but the music player keeping the CPU from going into the deepest sleep states. With Spotify it's likely the web-browser underpinnings (anything based on Chrome will suck down your battery even when it's doing nothing).
I can't believe that no one else commenting here is picking up on this. It's not about "tight code" or "fast code" - it's about CPU utilization and battery usage.
Windows still ships with Windows Media Player, which is what I use now. No idea how it rates in terms of efficiency but it does what I need better than any of the players he reviewed, and then some.
Specifically love being able to find music by year, and while not the simplest UI, it's playlist builder does what I need. Wish I could run it on my phone.
I do suspect however that my use cases are unusual in that I don't stream music, and have a large library replicated on my PC, Surface, and my phone - and I've spent years completing and cleaning up the meta data, which Windows Media Player makes really good use of.
I don't use WMP but I am the same as you. I don't stream. I see no use in constantly wasting internet on something I can download and manage diligently by myself.
Be sure that there's quite a lot of us out there still but we don't like to tout it, lest the cool kids attack. :)
I recommend you try foobar2000. I remember trying to play MP3 files on 486 DLC 120MHz. WinAmp couldn't handle playing MP3 smoothly on that, but foobar worked fine.
Even though a little late to the party, I just wanted to give my vote to the best Windows music client I know, XMPlay [0], which, with a minimalist skin [1], for me is unbeatable. Does anyone else use it?
Rockbox is an open-source project that replaces the firmware on many dedicated MP3 player devices. It's still under active development. Their most recent releases improved power usage to the point where my 6 year old Sansa Clip+ now has better playtime than it did on stock firmware when the battery was new.
It also produces objectively better sound reproduction, and can handle FLAC which the original firmware could not.
you can still get the old winamp (2.3), from before it got all maimed by AOL, if you look hard enough. I use it mostly for nostalgic reasons: old skins and AVS scripts.
As you said, Winamp + classic skin, with all the "features" turned off like Winamp Agent and those other stupid things they added after the AOL acquisition, is perfectly fine. The fact that OP didn't even try out (or discover) foobar2000 tells a lot.
Indeed. The OP did not close out on Winamp - Looking for an efficient music player, which is claimed elusive, and yet Winamp practically dismissed because of its website.
In Spotify I have my entire library in the cloud, accessible from my phone, home computer, office, etc. I get weekly (great) recommendations based on what I actually listen to. I can browse related artists, share songs with my friends, stream the music to all my home speakers in sync.
Of course an mp3 player use less power, it only does a fraction of what Spotify does. It's not even like comparing apples and oranges, it's like comparing your bike to a jet fighter.
And, yeah, I grew up with Winamp and MP3s (or even .MOD/.XM). But the world moves on.
Nothing that the official Spotify client is capable of requires it to be anywhere near as inefficient as it is. This is something I've looked into quite deeply, having wanted to write true native alternative clients for all three major platforms.
The biggest roadblock at this point is the way Spotify has been handling the deprecation of libspotify. They haven't made a replacement public yet, and the public web endpoints don't support playback like libspotify does.
However, with Spotify you're limited to the music that's in your Spotify library. On the desktop you can also add local music files, but they don't sync with the other devices.
I have been playing with making a player to learn a few audio decoding libraries. Using dr_flac, LAME, and nuklear for the gui I made a simple player. It turned out to be extremely efficient (cpu-wise, memory is the next step).
Nuklear, the gui part, I know to be extremely inefficient. Due to it not being called that much (refresh every 10ms, IIRC) it uses an insignificant amount of cpu time.
dr_flac and LAME are efficient enough, especially considering the work they do.
Note that LAME can do fixed-point, while dr_flac uses floats. This is very important when talking about power efficiency, as floats use much more power.
Sending the PCM data to the sound card (using ALSA) takes an insignificant amount of cpu time (memcpy to fill the buffer, that is ~172kB per second (44100 * 2 * 2 / 1024 ; 2 channels of 2byte samples at 44.1kHz)). Though ALSA (speex) resampling 44100Hz to 48000Hz does take a significant amount of cpu time (IMO best to resample while decoding).
On "modern" linux there is also Pulse Audio, that takes that resampling overhead from the program onto itself. Note that PA (idk if still) uses floats to resample, making it very inefficient.
Floats on modern x86/amd64 cpus are fast, as fast as integers (although float operations have a delay so it turns out slower). More important is that floats use much more power to compute. Another thing with power efficiency is that modern cpu cores go to sleep to save power, so one should not wake them up every milisecond to check on something.
As for the article;
>After downloading hundreds upon hundreds of kilobytes of zip file, fire up a shell, run mpg123, and wowzers. It plays MP3s smoothly and efficiently. A remarkable feat of engineering, especially considering it’s all written in plain old C without leveraging the synergies of dozens of frameworks. One wonders how they managed.
I want to say "no shit".. so... No shit. For multiple reasons.
>Time for an old standby? What’s Winamp up to these days? Oh, great, looks like more internet radio nonsense. And the website has the modern flat square design I’ve recognized as a harbinger of impending disaster. Sigh.
Winamp doesn't even get the chance because the website looks signals an "impending disaster" ?
Yeah, that was a strange remark. Winamp's website looks like it does because development on the program is kind of in a state of flux / suspension, with nothing happening since a few years ago when AOL sold Nullsoft and the latest version (5.666) was released. I find Winamp to be pretty efficient these days to be honest.
I've tried Tomahawk, WMP, VLC, and others. But they all have some stupid social connectivity, or rating/library organizing thing (so does Winamp, but it's unobtrusive), or just takes too many resources.
All my music is already organized (Ampache), I just want to play an M3U. VLC was a close second by the UI is too clunky for me (though I'm guessing skins and some customization can change that).
You should. It's extremely efficient, upgrades painlessly (your music is stopped for 5-10 seconds and boom, upgraded), has good skins and never, ever lags, or loads the system in any way.
If we remember, this was one of the key advantages of the original iPod. Read as much MP3 data into RAM as possible, then spin down the hard drive. Spin it up again when you've gotten to the end of the in-memory buffer.
To this day, the huge old Ipod 80Go has been the best mobile audio equipment I owned. So much so that I have in fact stoppes listening to music on the go when mine started going senile and replacing it was no longer possible.
Apple, this was the one product that meaningfully changed the game for me and many others. We miss it.
I mean.....ebay is absolutely full of either new or like-new iPods Classic in any capacity you want, I know it's annoying that apple doesn't sell them anymore but if you want one it's not exactly difficult to get one.
It was lack of rockbox that prevented me using ipod "classic" -- I see the classic port is still listed as unstable. I'm a mac user but I have never understood how iTunes is to be used.
Indeed you are correct. I merely regret that they added features in ulterior iterations that were at best accessory to what originally set them apart.
I mean, look at how the role of iTunes evolved!
I just use command-line program on Linux. Very easily to play the music. If you want a shuffled playlist, you can use the commands such as "shuf" and "xargs". You can use "head" to limit playback time, if you use music playing program that output to stdout instead to the speaker (and then use another program to send to speaker) (as far as I know the only music players that do this are ones I wrote myself, but other ones may well exist, that I do not know of).
I'm seriously considering switching away from Google Music because of this. The web interface, and every unofficial desktop app I tried, all use up 50+ percent of a cpu.
I thought this was going to start another Electron bashing thread, apparently the Spotify client uses the chromium embedded framework, with a C++ core. So its basically a fat web app consuming Ted's battery.
I'm surprised VLC wasn't mentioned here. I've been playing SomaFM's 80's station on my work computer for weeks straight, yet the vlc.exe process still clocks in at around 1-3% CPU and 25MB of memory.
I definitely agree with Ted's conclusion, though. We need an Energy Star (TM) rating for software.
My greatest affliction with music players is the UI inefficiency. They are so anxious to sell me their online services, that have bad searches, bad browsing, almost no information about the music (who's this voice singing together?), and slow to start.
Can anyone here recommend a good player for Windows?
I still use XMMS (not its slower buggier cousins like audacious or XMMS2) and it works super fast and great, having entire music library in the playlist. If I were using Windows, I'd use version 2 of Winamp which is essentially the same thing.
On Linux I use cmus in a guake window. Cmus is a curses-based music player / browser and guake lets me access it with F12 at any time. Launches almost instantly and I never worry about it consuming more resources than it needs.
My music player is very efficient, it practically doesn't waste any milliwatt-hour from my laptop's battery. The audio quality is good to superb depending on the source material.
It can display the covers of albums with excellent resolution and clarity.
The compatibility with the music formats is excellent, supporting most of the formats designed for the music player. Actually i can play most music from 1948 to 2017 on it, without any change in configuration.
With optional hardware it can support 4-channel surround audio, as well, although this isn't an user-friendly setup.
Not everything is great -- my music player isn't portable at all. It is big and weights more than 10Kg. It also doesn't support remote operation. You need to be there at the user console to change tracks, etc.
Records are actually a very very long-lasting information storage medium, better than magnetic tapes (even when you put redundancy checks on them). So much that sometimes when music from the 1940s to 1960s is to be restored, restauration experts use the record rather than the master tape, which is more subject to degradation.
As for degradation, in theory there is degradation every time the record gets played. In practice tests done in the 60s show that records can be played over 1000 times without significant deterioration of audio quality.
However, the record surface is very susceptible to damage. This means that, play a record over a worn stylus, or under a turntable with a too heavy tracking force or a poor quality cartridge -in short, a bad turntable-, and the record will wear down rather quickly, sound quality will be degraded quickly.
Or, as is my experience, a piece of debris is missed when putting the record away, and scratches the surface significantly when put into its (usually too-tight-fitting) sleeve and cover.
mpv and vlc are more than enough for all my playback needs. Besides Rockbox on a portable Sansa player, which can actually play Opus files, unlike various similar solutions.
He's on Windows and didn't mention foobar2000? I've been using Linux exclusively for almost ten years now and foobar2000 is the only program I still miss. Banshee does an acceptable job, though.
It's a real shame that MOC doesn't support Pulseaudio out of the box. I say this because I almost have to use Pulseaudio (Firefox has removed ALSA support) and thus if I want to play a Youtube video (or any audio in firefox) at the same time as listening to music, I can't, unless I either download and compile the Pulse-enabled fork for MOC, use a different browser, or use a different music player.
MPD comes close to MOC but it's too complex to use for me, and some clients don't actually list all of the files in my library.
I might just go back to Clementine, if it works. That's what I use on Windows.
I just got bit by the new Firefox dependency. Installing PulseAudio left me without sound in VLC (even though I'm using the PulseAudio output plugin) and Firefox can't play videos anymore.
I haven't tried apulse -- I solved the problem by not using Firefox anymore -- but I hear it gives good results.
I ended up trying apulse myself last evening and it seems to work fine, so crisis averted for now. I don't particularly enjoy having stuff much with LD_PRELOAD and friends but I suppose it's less effort.
Thing is... I know what you're saying, and I don't doubt it's probably just some trivial issue that I can solve with a two-hour trip to Google and my PA config files. However, not running PA works fine, and has been working fine for like 12 years on every computer I've owned. It's literally no effort at all. I could spend some time getting sound to work again, or do absolutely nothing at all and have it working fine, just as it's worked for the last six years on the machine in question.
The days of endlessly troubleshooting ALSA settings and OSS wrappers aren't really gone if we're troubleshooting PA settings and ALSA wrappers instead.
PulseAudio has an ALSA compatibility addon, where it registers itself as the default ALSA device and therefore can be used by applications that can talk to ALSA only. In Arch, install the pulseaudio-alsa package. On other distros, refer to that distro's documentation.
Internet > dl file > convert decrypt > read file > play > remove files after max cache reached
The internet/downloading takes a lot off power.
The filesystem is also in use far more
The encryption takes a lot off cycles as well. The reason that it is there is so it won't be a glorified music piracy software ala napster/kazaa/limewire.
At one point Apple removed indy apps from their store which cached youtube music to file system for offline listening. A nice feature, but music is copyrighted and has
a rich history with lawsuits. You can't just stream music, because streaming in this context is same as downloading.
All battery munching things that add up, but which are essential due to the nature off the data.
Furthermore, Spotify needs to run on ios, android, windows, linux and osx.
For this needs far more intricate code than a player for 1 OS. Optimizing individually for each and make it shared platform is no easy task
I agree a lot needs to be better, but there is quite some bias and overlooked factors.
Modern wifi is surprisingly efficient and shouldn't make much of a dent on a laptop-like device.
There doesn't need to be much of a difference. Decoding encryption is no good excuse to bump it up to multi-GHz range -- even at high quality, compressed music comes at no more than a few dozen kilobytes per second. That is nothing.
Unless the application is pre-caching entire albums, encryption & decode aren't a good excuse.
Portability has nothing to do with it either. mpg123 runs on lots of systems. "I must run on Linux so I use 3.5GHz on Windows!" said no application. Ever.
Presumably the ideal wifi system would transmit with as little power as needed, but would ramp up power when faced with thick walls, long distances and interference.
It likely just isn't a concern for them. Just as making page loads lightweight isn't a concern for most press-like organizations that prefer to serve megabytes of script, pictures and ads across dozens of requests.
Bloat and inefficiency is the way it goes in this industry, and these companies are too big to care if tedu doesn't like the way the cycles are wasted. Solo developers may have different priorities.
I remember well the anecdotes of working for Steve Jobs. Devs sitting through an entire weekend just to make the transition for switching between menu's precise to the millisecond. This one is slightly hyperbole, but the point is standards.
It's no coincidence the ipod is the most famous music player in history ever.
Devs might see the issues with the code, but as you say, a lot off people in high places give 0 shits.
I've had this happen myself at many companies I worked with. I found a way to be more efficient and u get false promises of it being adressed in the future or your advice gets ignored, or dismissed as a waste off time.
At worst u become the know-it-all who "can't let things go". Fun times..
While there are many inexperienced devs. A devs work is only as good as the standards of it's "captain".
Do what I do. Don't ask them for the extra time. Make it a challenge for yourself to create the better solution in the allotted time budget. Or make it a side project (10-20% time).
I may be becoming too cynical or slightly old but I don't care if the businessmen are smart enough to recognize a good investment in quality. I am not interested in educating bean counters. I simply don't ask them and I leave them no choice. I invest in a future where I won't be cursing myself or them. They never know it and we're all better off.
Do I understand you correctly in that you attribute increased power usage to the intricacies of copyright law (at least in part)? Because that's an interesting angle that I hadn't even considered yet. :)
Well, I opened up my supposed music cache from Spotify once and u dont get a list with audio tracks, but encrypted data. The cache was about 12gb large so it must be the audio.
If it was the pure audio source then nothing stops me from copying it and put it in my own library, possibly shared with anyone through my own NAS avoiding ads and future subscriptions.
I could also just stream the cached folder into my own app, and while losing the ability to pick songs in real time it effectively becomes a radio given the main client keeps running, which I would do on a random cheap pi or server.
Someone else mentioned VLC's GUI sucking, and that is so true and such a pity, both for the playback and conversion/transcoding abilities it has. I don't mean graphical skins, mind you, it just needs (a lot) more love.
Sometimes the excuse is that cpu and memory are cheap as if resources aren't under constant pressure from the hundreds of processes that all pretend they are the only one on the machine.
Many also don't know how to draw simple, low-overhead abstraction boundaries. Everybody wants to make the most generic code planning for things that will never happen or at least not in the way they think. You can't call out most people on this because this one piece of code they are working on is always the exception.
And most developers don't know how to optimize as they write code. They often don't understand the problem or have enough mechanical sympathy to understand what code you should probably be careful with and should be made quick to start off with. They probably don't understand the cache system enough to know why that linked hash table is probably the wrong data structure. Hash means fast to them, and to them this is all premature optimization even when the correct solution is probably no more difficult than what they are doing. Calling something premature optimization is often used to shut down discussion of how their code can be improved.
The field is too in love with horribly inefficient frameworks. Writing network code and protocols is now considered too low level for people. Many are too caught up it what is tech-cool. They're like the holistic medicine practitioners of software and they don't even know it.