Hi all,

I have successfully compiled libmikmod for Empeg and created a very small dummy player with it.

However, I ran into a few problems: after the first pattern, the sound starts getting distorted. The first pattern plays fine, after that, a sound block seems to be followed by a blank block then again by a filled block etc.

Is this due to a bug in libmikmod or is that related to the player hardware?

Also, would anybody be interested in seeing mikmod ported to the Empeg?

Till

Hi.

from what I know, the hardware is almost 100% unrelated to this problem you experience. This counts for the empegs kernel just as well. It might however be a problem that the kernel does not provide full OSS compatibility (it does limit the blocks send to /dev/audio to be a certain size (4000something bytes or samples, I am not sure about this and would have to check the sources to find out).
I would first look at the player code (your player), perhaps you are (unknowingly) doing something nasty with pointers. If you are sure your player isn't the problem, check the (ported) lib.
AND: I would certainly be interested in a .MOD/.MID capable empeg (especially if that functionality would be in the "official" player software somehow (I would prefer a nice plugin-interface, like it was promised some (long) time ago).

cu,
sven

proud MkII owner (12GB blue/green/smoked, #080000113)

It seems that the problem is somehow related to the player internal double-buffering of the raw sound data.

I am using just a raw sound device hardwired to a buffer size of 4608 (as stated in various places, I got an error message otherwise anyway :) ). The raw sound device just sends the data to stdout which I pipe to /dev/audio or /dev/dsp.

When the player moves on to the second pattern of any song, it seems to be playing a filled buffer, then an empty (zeroed) buffer, then a filled buffer, etc etc.

The first pattern plays perfectly well though. I don't know what is causing it, I will try an older version of the library to see if it is there, too.

I have been working with MikMod long ago and afaik it only allocates the buffers once, then keeps overwriting it - so there shouldn't be a memory issue or anything.

Till

Hm, I can say that I have it working now.

However, sometimes it seems that little Empeg can't keep up with mixing the sound in real-time. libmikmod is definitely not the fastest mixer around, but, it should work on anything that can play MP3.

Again, would anybody be interested in using mikmod? Also, if so, would anybody be interested in hosting binary & source? I won't have my own page until sometime this autumn, so if there's interest out there...

I'd especially look forward to some input that other people have regarding the current glitches etc.

Till

"Little empeg" is a 233Mhz StrongARM box - if a MOD player takes anything much over 10% CPU time it's certainly having problems with life.

We had some perfectly good 8 channel tracker routines on 8Mhz ARM2 machines ten years ago, using around 30% of the CPU.

Rob

That is what I was wondering about - a while back I did a software mixer in assembler on a 80286 running at 12Mhz, it ran pretty well.

Anyhow, I think I found the problem. When running in polling and not DMA mode, the default code used an usleep() in the main loop to free some spare cycles.

This, in combination with the raw output device, seemed to result in blocks being rendered at the wrong times. Removing the usleep() fixed it, but I still don't really know why this was such a big issue.

Well, player runs smoothly now.

Till

Hi Till.

Also, if so, would anybody be interested in hosting binary & source? I won't have my own page until sometime this autumn, so if there's interest out there...

I could host the files plus a small (part of a) page along with it.

cu,
sven


proud MkII owner (12GB blue/green/smoked, #080000113)

It would only be a diff for the libmikmod (hardwiring the buffer size for stdout) and the small player. No real instructions needed. :)

But as you were saying in another post, how about setting up a few Sourceforge projects and linking these together with the existing dev sites?

What would also be very interesting is a knowledge base where everybody could enter information, hints, tips, tricks etc into a central database. That could easily be used for generating a FAQ-like documentation.

Especially, what I needed, as a terrible newbie - step-by-step serial connection and working on Empeg's file system. It's not terribly hard to find out, but it's better to be assured reading that others are doing the same way you do.

Till

Especially, what I needed, as a terrible newbie - step-by-step serial connection and working on Empeg's file system.

The FAQ section of this BBS has got step-by-step serial connection instructions under the "Hyperterminal" subject. For working on the file system, I think I have provided a link to some Linux help documents...

___________
Tony Fabris

I saw that one with Hyperterminal on the mars.org site, it gave me a start, but for some reason the player would _not_ drop to the shell after pressing Q.

Also, I noticed that the DSP seems to go into some sort of idle mode and needs initialization by the default player before you can output sound.

All this info is so widespread across different people's pages that I think the current Empeg hackers out there should join forces. :)

I don't want to criticize here, I think I read most of the active poster's pages (dev. related or not) and am impressed by what people do and have done with the Empeg.

However, this "tie it all together"-point is missing, even though smu seems to start working on that right now with his new page.

The webring is also a good idea (just on a side note), I am familiar with PHP programming and I bet there are existing scripts, that shouldn't be hard at all.

I'll be terribly short with spare time until end of August though, otherwise I would have tried to work something out.

Till

I saw that one with Hyperterminal on the mars.org site, it gave me a start, but for some reason the player would _not_ drop to the shell after pressing Q.

I wasn't referring to the mars.org site. I was talking about this entry in the FAQ forum here on this BBS. In the FAQ it gives two possible reasons this might happen:

1) You haven't installed the developer software onto the empeg.
2) You haven't cycled the power on the empeg.

Also make sure the software is set to the correct terminal settings as illustrated in the screen shot in the FAQ.

However, this "tie it all together"-point is missing, even though smu seems to start working on that right now with his new page.

The mars.org site was supposed to be this "tie it all together" site. I would still like to see it become that. Unfortunately, it's way behind on updates. I have forgotten who runs it. Is that PaulH's site, too?

___________
Tony Fabris

Ah, _that_ FAQ. Missed that entry, and a very good entry indeed.

As for mars.org, I'd be very willing to help updating it if that is ok with the original owner. Maybe it can then also run a (possible) webring.

Till

However, this "tie it all together"-point is missing, even though smu seems to start working on that right now with his new page.

The mars.org site was supposed to be this "tie it all together" site. I would still like to see it become that. Unfortunately, it's way behind on updates. I have forgotten who runs it. Is that PaulH's site, too?

These were exactly my problems with the mars.org site: Updates weren't made to it since about a year ago. Many many many things happened in the meanwhile, and it is still not updated.I mean, just read the "What's new" section of it. the latest entries that matter for developers are:

Developer's Mailing List   01 Feb 2001 Modified instructions 

Demo Code                  28 Jul 2000 Added C-64 SID music player 

Hardware Mixer Information 30 Mar 2000 New code to toggle the Soft Audio Mute

Nothing happened on the developer mailing list sind about august 2000 (if not longer), so the update on instructions regarding that mailing list is rather useless. So the latest updates on the side were done 12 respectively 15 month ago.
However, I hope this might change. I'm willing to shut down my empeg related infos and instead incorporate these in the empeg.mars.org site. I'm however not willing to spend a hell lot of time on adjusting my infos to the empeg.mars.org layout/design (that I like even less than the one of my own pages).
It seems as if these days, some developers become active in programming for the empeg.
The first thing we should clarify is the way we communicate with each other. It is ineffective and even destructive to use too many different ways. So what should we use? This board or the mailing list or a new mailing list?
The second thing is the way to handle common knowledge (or the knowledge we want to share). We could use empeg.mars.org, we could use *.incase.de (i.e. any host in that domain, might as well be part of my existing website, or a standalone one), we could use the FAQ section of this BBS (micing programming info with user info).

cu,
sven

proud MkII owner (12GB blue/green/smoked, #080000113)

In reply to:

---

The first thing we should clarify is the way we communicate with each other. It is ineffective and even destructive to use too many different ways. So what should we use? This board or the mailing list or a new mailing list?

---

Usually, at least in the development areas where I am active, there's either a mailing list, a newsgroup or a board. Mailing lists and newsgroups are most common and effective, while a board can do the same (but probably has some disadvantages).

The hassle of registering a newsgroup is too much for a start, so the only alternative would be a mailing list. I wouldn't want to step on anyone's toes and say "we have to have a mailing list no matter what", because this board is well-established and it _works_.

If at all, I'd say a special-interest mailing list for developers only as it exists already and reactivate that one.

On top of that, I'd suggest an IRC channel to hang out and meet, probably with a focus on developing but for everyone else, too. This proved useful many times, you have people to chat with and problem solvers with hints, tips and tricks are always at hand.

Till

There is a developers mailing list set up and still working (I believe, as I got a mail from Roger L this morning on it). I haven't seen much traffic on it in a while, though. The addy is [email protected]. I think you can just mail to subscribe to get on the list?
Jason

_~= Dearing =~_
"WAY too happy about having #99."

Yeah, I just joined that this morning. Apart from my test posting, there's been no activity since last year, according to the archives.


Roger - not necessarily speaking for empeg

I was just wondering if your player can be downloaded at the moment, still have a bunch of these mod files and I'd love to try it.

[email protected]
--------------------------------------
Reg:1934/Mk1:158-6Blue(sold)/Mk2:380-12Amber

Hi.

Till's MOD-player is available through my (still preliminary) website at www-new.incase.de in the empeg/files subtree of the navigation. The URL will change to www.incase.de some day in the not too far future.

cu,
sven

proud MkII owner (12GB blue/green/smoked, #080000113)

Hi there,

I will soon release a special driver for libmikmod that should work with all versions of MikMod. MikMod's behavior for buffer sizes that are not a power of 2 is unspecified according to the developers (strangely so, I would understand if they'd mean a multiple of 2, but a power of 2...?) so I will create a driver that will put in an extra buffer to satisfy MikMod _and_ Empeg with its "I only like 4608 bytes". :)

Right now, libmikmod 3.1.6 seems to work fine with 4608 bytes, though. (binary is included)

Till

Have you tried running mikmod through dd? You can tell dd to reblock, with "obs=4608".

Hugo

No,

I did not try that yet. Good idea actually. However, I don't even like having to use the stdout driver and piping that to /dev/audio... sending the sound output to various shell utilities looks pretty dirty to me.

Also, as Empeg is a full-fledged sound device, why not create a full-fledged driver for it...

Till

John (new john) has fixed the 4608 byte limitation in the sound driver for the 2.4 kernel on an upcoming product; this will hopefully find its way back into the v2.0 release.

Hugo

John (new john) has fixed the 4608 byte limitation in the sound driver for the 2.4 kernel on an upcoming product; this will hopefully find its way back into the v2.0 release.

Just dug up this old thread and noticed there was talk of removing the 4608 byte limitation... Any chance in reviving this request for a future 2.x build?

It will be interesting to get this going. Maybe we can
talk the devs into supporting mod formats in a later version
if we get it up and running well.

Ed