writing different player software??

I know this is probably the worst time for this question seeing how beta 11 just came out, but has anyone ever tried to write player software for the empeg? I mean a lot has been done and *most* of the empeg is open source except for the player code which I can totally understand. But when reading the FAQ there was a notion of 'if you wanna write new software to play MP3's, go right ahead'. I just want to know if anyone has actually tried it?

I'm not trying to insult anyone at the Empeg team or anything like that. The current software is brilliant and I'm downloading beta11 right now! But I am concerned that, in time, the player code will get neglected and it might be nice to have another option.

later,
ajay

AFAIK, no one has tried to write replacement player software. It should be possible, with one major qualification. I think that the API (or whatever) to control the DAC is restricted by NDA, and it would be pretty hard to do much useful with the empeg unless you could control it. Unless it just defaults into a sane, easy to write to, mode.

There was a pretty long thread about doing this a while back when everyone was getting impatient with the 2.0 release schedule. That thread is here. And it's been talked about a few other times as well.

*most* of the empeg is open source except for the player code

That does make me smile..

Rob

The sound output is in-kernel, so no problems there. Reverse-engineering the Tuner interface is trivial, unless you live in the land of "freedom" (USA) where it might land you in prison.

I think someday I might work on something like this, to get around the limitations of the current player software. But then again, it probably isn't worth my time, and the current player is Pretty Darned Good software for the moment.

just out of curiosity... what would you define the limitations of the player as?

For starters:

The sideways scrolling menus drive me batty, and really hinder front-panel playlist navigation.

Inability to effectively manage a running playlist from a third-party app.

Inability to record on the fly.

Missing just about every feature that's been added to Hijack, and then some.

No OggVorbis support.

No source code for end-user customization.

I'll second the side scrolling thing. The Rio Reciever uses a vertical navigation scheme that "feels" much better.

But lest I offend the team that produced this excellent product, I really do like it. A LOT!! (thanks, guys!).

-ml

haha. Well... at least i can say that the interface that i like a little better was ALSO developed by them. =]

I can't realistically see anyone writing something that would be a general replacement for the player software, but maybe an alternate player that works differently to suit your own needs.

I'd be interested in hearing what functionality you'd put in your own player software that isn't already covered.

If you're serious, I'd suggest checking out madplay as an mp3 decoder. It's all integer based, and has sucessfully been ported to the tivo which has a 54MHz ARM chip. Or if you wanna write your own decoder, you could start by reading this.

I really, really want a player that chooses tracks from the whole system, choosing the most popular most often and least popular least often and the abilty to change the popularity on the player on the fly. I've wanted to do this ever since I first lusted after the mp3mobile. I'm constantly frustrated by the fact that I can't think of any way to do this with the current player. ( well maybe if you intercept open calls from within the kernel and redirect them, but this get horribly messy, not even sure it would work )

Sue.

That functionality could be minor work to add to the current player and emplode. If you'd want to use the "plays" counter to indicate preference, then you could also write a small program to manipulate this stat in the db. Then it's a matter of making some custom shuffle modes... It's hardly a feature that would warrant writing a completely new player application.

Bruno

Wow, Mark, you've pretty effectively summed up some of the biggest limitations in the current player software.

And I know you're not trying to put down the current software or anything, you're just being honest about some major top-level player features you'd like to see. I think a lot of people would like to see a player with those features. I mean, we all agree that the current player is great, but there's nothing wrong with shooting for the ultimate in perfection.

As I understand it, the only thing preventing a highly skilled developer from implementing a totally new player with those features is time.

Some of them (like the recording limitation and lack of Ogg support) have valid reasons for not existing in the current player software. But with enough time and energy, even those could be worked around.

One thing we need to consider when looking at the idea of writing new player software is this: In addition to implementing those new features, you also have to effectively re-implement all the features it currently has. Even if you grossly underestimate the number of man-hours required to do that, it's still a daunting task.

So, if all it takes is time, then why would you even question Mark's ability to deliver? He apparently has nothing but time...

I actually don't believe it's as big a job as it first looks.

If I were to do it (I don't currently plan to, btw.),

I'd get the .mp3 decoder from xaudio (same as original player did, I think), which is cheap, with sourcecode, and works okay.

I'd skip WMA completely, but if anyone wanted to add it, they could. The RioCar only just got WMA on Friday anyway, so that's not a big deal.

The menus, and nearly all of the "features" on them, appear rather trivial to implement. With tons more memory to play with (compared to Hijack), they could be downright easy. It's just that the sum of them all tends to be large. But nothing really daunting there.

The Prolux Visuals.. ugh.. MASSIVE programming job for those.

Some of the larger pieces of software are Emplode, Emptool (and JEmplode), all of which could just be left as-is, so long as the new player used the same database files/format. There are advantages to this, in that the new/old players could be swapped at runtime (by Hijack!).

Going forward, JEmplode could be enriched with new features, Emplode would rot, and emptool would need to be rewritten (too buggy as is).

-ml

All of this pre-supposes that the development team are all dead, the company is bankrupt and all development has ceased.
Of course none of this is true.
The dev team are alive and well and are still adding new features and taking suggestions for changes.
The company is also alive and well and developing new products based on the empeg, which means..
Development has not ceased and that new developments can be translated into empeg improvements.
In short, it may not be a huge job to write a whole new player implementation, but why bother, the dev team seem happy to add changes for us!

Just my (long winded) 2 cents
TTFN

If you think the visuals are the most complex bit of the player, you're way off; the player complexity is huge to make it "just work" seamlessly and intelligently. WMA has been in the player since 2000 (it was in the Rio Receiver, which builds from the same tree) but legalities needed sorting out before we could release it.

However, you could do a quick job and have something which appeared superficially to be much the same, but the last 20% to match the current player would take you several times as long as the first phase - there's a lot of hidden complexity in there behind what appear to be "trivial" features.

When we say there are many man-years of work in the player, we're talking man-years of work by people who are the best programmers I know, not by code-monkeys.

Hugo

Yup, that old 80/20 rule.

This is what I meant by the "grossly underestimate" comment in my other post. If all you go by is the user interface, every piece of software looks easy to write. The tough things are the things you can't see, like the caching control, the fast database indexing, the playlist management, etc.

This is not to say that I don't think it could be done. And if anyone could do it, Mark could. There's also no reason that a replacement player would have to be as good as the original player software in each and every aspect.

Mark, the only comment I have about your list: If you choose to embark on the project, please don't use Xaudio. The empeg guys dropped it for good reason.

This points up another problem of writing your own player software: Re-inventing lots of wheels. The empeg guys learned a lot of lessons in writing the player software, and anyone who tries to follow in those footsteps wouldn't have the benefit of all those learned lessons.

I wasn't talking about "complexity", which doesn't frighten me in the slightest, but rather sheer mass of programming effort. And on that front, the Visuals are the biggest job: tons of excellent hand-written ARM assembly code, and very well done.

Rob, I have only praise for the product and the team behind it. But the company behind them is unlikely to be around for more than another year or two, and I really really like my Empeg player.

However, when investors finally pull out the rug, a lot of IP such as the player software will be lost to the community, possibly forever. When that happens, I may just re-implement the player software, so that we have something the community can share and improve in the future.

Sure, seamless playback is complex and difficult to achieve, especially if one is recent to real-time embedded stuff, and if the hardware is being co-developed, and the O/S is new and unstable. But second time around, a lot of that becomes easier.

Sure, it would take longer than my part-time Hijack enhancements took, but it wouldn't be the biggest job I've ever tackled, and I already have more than enough of the Linux depth and breadth required, and a 20 year background in real-time embedded design. I would not be starting as close to scratch as your team did a few years back.

But in the meanwhile, Empeg/SB's years of effort and devotion are not in question here, and I really don't mean to belittle any of the past efforts embodied in the player software. It truly is an amazing product, and around it here it speaks clearly for itself (there are FOUR (4) of them on the desk in front of me).

Cheers

-ml

And there I go confusing Rob and Hugo again.. darn!

Anyway, Great Product, Hugo!

But the company behind them is unlikely to be around for more than another year or two,

Heh, wow, that was almost a troll.

Rob and Hugo are surely going to jump in here and defend this. But I do see how you might come to this conclusion, based on the descriptions I've heard about Sonic|blue's order-fulfillment problems.

MMm... yes, I suppose it could be taken that way. Not quite what I meant, but rather, I was just factoring in recession, dot-bomb, lousy North-American customer service, continued quarterly losses, and likelihood of attracting attention from the RIAA, all along with typical lifespan of any company of that type even in good times.

They'll bomb. Or be swallowed by a bigger fish. And we'll lose the incredibly wonderful player updates we've seen lately.

Cheers

-ml

Actually my prediction is that SonicBlue *themselves* get bought out by a larger company with better marketing and management of its resources. They've got a LOT of nice intellectual property lined up in their products that has a lot of value. Before the mis-management and poor order fulfillment destroys the company, I would imagine a "technology giant" would swoop in and realize that there's "a lot of gold in them thar hills."

I'd like to request an official END to all discussions of the possibility of company X being bought by bigger and better company Y. I'm not one to be superstitious, but we don't want to "jinx" anything all the same. This is starting to remind me of Commodore and the Amiga - and it's something I don't want to see happen again. The company I work for bought FireGL from SONICblue, but I don't think they'd be interested in the Rio brand.

Bruno

I agree with mlord about SB. With the industry in the state it is and the economy, i just don't see it. No reflection on SB or the empeg team especially, it's just the way it is. As to ATI (the purchaser of FireGL), their 4Q income was a measely $2.2MM or $0.01/share. Their earnings margin was only 1% on revenues and I am sure a lot of that is from cooking the books. How long are they going to last with those earnings and the merging of onboard graphics chipsets?

As to officially requesting and "END" to any post empeg discussion, what good is that?

We're not in any position to be taken over or to bow out of the market if that's what you're trying to get at. I would be a lot more worried if I were at NVIDIA (long-term that is).

Bruno

I was not trying to get at anything except the state of the industry/economy is not favorable and with mlord's right to discuss the future of RioCar. You have to admit it's admirable what he's accomplished and certainly he seems fearless.

Certainly the gamer's choice (for now) seems to be NVIDIA. Why would you say NVIDIA should be worried long term?

I won't discuss why I made the comments above. I'm under NDA and most of what I know is very confidential, whichever way you slice it. I'm confident in the company I work for. That much I can say.

NV has built a very good name for themselves. Even if the new chip is completely inferior to our 8500. It certainly a bit of a speed boost to the GF3, but it's much more of a GF3.1 than a GF4. For laughs, read the "review" over at Tom's Hardware. "Laughs" because his site and his "knowledge" is a complete joke. Anyway, the big money isn't in retail sales of the top chip.

Mark is an experienced and proven kernel-space programmer. He's blown the door wide open for other people to play and hack with the empeg. I don't know how the community could ever thank him enough.

Bruno

I won't discuss why I made the comments above. I'm under NDA and most of what I know is very confidential, whichever way you slice it. I'm confident in the company I work for. That much I can say.

Who's confident of anything these days? www.enron.com

I don't know how the community could ever thank him enough.

By writing user apps, silly!

Heh, thats what I am trying to do, write a wrapper/manager for the d.net client that ties into the hijack menus. Between finding a 10 line C program that crashed and my nap, I didn't get much done today though.

Yeah I have a couple unfinished apps too... But I *never* feel like programming when I get home because it's what I do for a living... Kinda like how the gynecologist never wants to... ah, nevermind.

I did give the alarm clock thing some time this weekend, but it's Not Quite Ready yet. The lyrics scroller will get my attention after that.

>Mark is an experienced and proven kernel-space programmer.
>He's blown the door wide open for other people to play
>and hack with the empeg. I don't know how the community
>could ever thank him enough.

Hey! Any similarities to godness are just an accident of naming. So before y'all get me confused with the BBS SysOp (who is God), just remember I write software with my own best interests at heart: I want my Empeg to work even better!

Thanks Bruno!

Plus Mark is Canadian. Ya!

Bruno

eh!

> That functionality could be minor work to add to the current player and emplode

You are right. It would be minor work to add to the current player, but without player source, it would require some major hacking to get it working with the way things are now and I've seen no indication that this functionality may be added to the player.

Sue

Emplode would rot

Oh, I doubt that . If you reimplement the player (completely) from scratch, I'll make emplode talk to it.

Deal?

No OggVorbis support

We've said it before, we'll say it again: If someone can find (or write) an LGPL- or BSD-licensed integer implementation of Ogg Vorbis, then we'll consider integrating it.

>We've said it before, we'll say it again: If someone can find
>(or write) an LGPL- or BSD-licensed integer implementation of
>Ogg Vorbis, then we'll consider integrating it.

Yes, I'm sure you would.

You can do this by using a custom shuffle in config.ini
This functionality was in 1.1. I don't know if it is still supported in 2.0

>If you reimplement the player (completely) from scratch,
>I'll make emplode talk to it.

Well, be careful with such promises, they may come back to haunt you.

But with an existing free, open-source, multi-platform implementation (JEmplode), that may be unnecessary.

Cheers

Brendan at phatnoise is working on a integer based decoder. He said his boss wants to release it as open source when hes done. :-)

Sean

Brendan at phatnoise is working on a integer based decoder. He said his boss wants to release it as open source when hes done. :-)

Do I see an Empeg-Phatnoise partnership on the horizon???

You can do this [mserv-styley play-favourites-more-often] by using a custom shuffle in config.ini

True, but (especially in terms of UI) that's a pale shadow of my plans for that feature...

Peter