Amiga.org
Amiga computer related discussion => Amiga Hardware Issues and discussion => Topic started by: AmigaNut08 on June 09, 2009, 02:49:45 PM
-
Hi all. It seems that i am not having any luck at all with any new Amiga hardware i get these days. I just tried out my new MP3@64 Audio decoder in my A1200 only to have the audio skip and stutter so bad that it is torture to try and listen too it. I am using the mp3at64mpeg.device and Amplifier to play the mp3's. I tried different settings but to no avail. After thinking that Amplifier might be the problem i tried an mp3 with the shell based player that comes with the mp3at64mpeg.device, mp3at64play but i get the same results.
In the readme is the following.
Known Problems
~~~~~~~~~~~~~~
- Sometimes the sound is interrupted for a short period. Seems to be a bug
in the timer.device that sometimes causes interrupts to be delayed. I
tried very small intervals, but it still remained, so I guess it's either
a bug in timer, or the system interrupt load causes high latencies.
Is anyone else getting stuttering and skipping audio or is it just my luck to be the only one affected??? If others are getting smooth playback i'll try this card in my A2000 equipped with a Buddha Phoenix card, which is the Amiga i intended to use this on originally.
-
What OS are you running on your A1200? Maybe something is interfering. You might try to boot without startup-sequence and check if you get better results with the command line player then (not sure if this will work though).
-
What OS are you running on your A1200? Maybe something is interfering. You might try to boot without startup-sequence and check if you get better results with the command line player then (not sure if this will work though).
I am running OS3.1. Although the MP3@64 is not meant to put a load on the Amiga's CPU the Apollo 1240 (040@40Mhz) felt some strain as the system was very laggy and the screen flashed black very quick(like a blink) on 2 occasions while playing mp3's.
I was going to try the command line player with no startup- sequence but i then got side tracked and forgot. I cant be bothered opening the A1200 up now to try, plus i am more anxious to see how it performs in the A2000, which is the Amiga i really want to use it in.
Cheers
-
I'm using it in my A4000/060 on the clockport of my Xsurf card, and when playing MP3s and shoutcast streams I have smooth playback with Amplifier, AmigaAmp, Streamer and AminetRadio.
Only occasionally sound is interrupted.
-
Have you tried to make the (pre)buffer as big as possible ? If set to low, you'll get the effect as described.
x303 :D :D :D
-
How much RAM do you have installed?
-
Sorry, bit late onto this thread, but can any of you confirm that you're using the MP3@64 off the internal clockport on an A1200? And if so, how did you achieve this? Using a clockport riser I guess? Also, how is performance? Like, what's the highest bitrate you can play on your machine and with what software?
I'm currently using a MAS player for an ongoing MP3 jukebox project, and I might consider going the MP3@64 route if it's less CPU hungry than the current parallel port transfers...
-
I'm currently using a MAS player for an ongoing MP3 jukebox project, and I might consider going the MP3@64 route if it's less CPU hungry than the current parallel port transfers...
The only CPU power I can imagine is used in MAS is accessing an IDE hard drive. If you have a DMA capable hard drive then it should be very little.
The same overhead will be present if you switched to MP3@64
-
Have you tried to make the (pre)buffer as big as possible ? If set to low, you'll get the effect as described.
x303 :D :D :D
I tried double the standard setting and then tripled the values. But still not acceptable. I'll try some over the top values and see if that helps next time.
-
How much RAM do you have installed?
I have 18 meg all up. the standard 2 meg chip on the A1200 and 16 meg on the Apollo 1240. After boot up and the player loaded, i have over 13meg free.
-
The only CPU power I can imagine is used in MAS is accessing an IDE hard drive. If you have a DMA capable hard drive then it should be very little.
The same overhead will be present if you switched to MP3@64
Well, I'm trying to keep to as little additional hardware as possible, so it's a bog standard A1200 with an 030/16 and a hard drive at the moment and little else. Surprisingly, the MAS does use a bit of CPU power, and I guess uses a lot of interrupts for its tight timing. It uses the parallel port, but not in parallel, if you get me - all the data has to be converted in software to serial for the I2C bus that the MAS chip requires. If the MP3@64 didn't need to do that conversion, it should be easier on a little machine like mine...
Especially since I'm writing the software and it's not exactly efficient ;)
-
Sorry, bit late onto this thread, but can any of you confirm that you're using the MP3@64 off the internal clockport on an A1200? And if so, how did you achieve this? Using a clockport riser I guess? Also, how is performance? Like, what's the highest bitrate you can play on your machine and with what software?
I'm currently using a MAS player for an ongoing MP3 jukebox project, and I might consider going the MP3@64 route if it's less CPU hungry than the current parallel port transfers...
I did use the MP3@64 off the internal clockport on my A1200. I used a clockport extension cable (Male header to Female header) that i ordered from Amigakit. The MP3@64 can play any bit rate. The player i used was Amigaamp. The sound quality (when it did not stutter) is brilliant. I would recommend purchasing the MP3@64 as it decodes the MP3 audio without the use of the Amiga's CPU. Now if only it played without stuttering. I am going to have to try this in my A2000 this weekend and see if it performs better.
-
Thanks for that! Yeah, it's the stuttering I'm worried about - I was thinking it could be a factor of DMA timing or something which affects certain A1200 motherboards. The MAS Player uses the same decoding chip as the MP3@64, but like I said in my previous post, just takes a little bit of CPU power to do a serialisation of the data before sending it out the parallel port. It's a shame there's nobody living nearby I could borrow one from to test it :(
-
I have an mp3@64 connected to the clockport of a kickflash in my A4000/CSPPC ... quality is EXCELLENT, and it even plays 320kbps VBR mp3's without problems... only the little delay pops now and then, as Chris explains in the readme...
-
Thanks for that! Yeah, it's the stuttering I'm worried about - I was thinking it could be a factor of DMA timing or something which affects certain A1200 motherboards. The MAS Player uses the same decoding chip as the MP3@64, but like I said in my previous post, just takes a little bit of CPU power to do a serialisation of the data before sending it out the parallel port. It's a shame there's nobody living nearby I could borrow one from to test it :(
DMA timing is what i am thinking also. Remember the timing issues A1200's had when faster cpu cards came out for it. A mod had to be performed on the mobo because of timing issues. I was also unable to get my ethernet adapter to work through the credit card slot as i was told my mobo also needed a mod done because the port would not reset with the given software. I was unable to connect to my router so i ended up selling the ethernet card. Not all A1200's suffer from these above mentioned issues (thank god the Apollo1240 worked as i believe this mobo was modded before i bought it) but knowing my luck i am probably in the minority of people that have had issues like this.
PS: Anyone out there using the MP3@64 in an A1200??
-
Yeah, there are known issues - and sometimes they only show up for other hardware, so it's possible that the machine is unmodified and works fine without anything on the clock port, but putting something there upsets it. Since I'm running an 030 it may well be better.
BTW, the network card issue is known and there's a software fix for it, should you want to try it again. Worst case scenario, it can be hot unplugged and plugged back in to reset it manually...
-
Hello,
I also use the MP3@64 device on the internal clockport of my A1200, rev1D4, with Apollo 1240/40. I also experience some sound skip when playing back, but only on MP3 with bitrate 192+. Below this bitrate, there is no sound interruption at all. The sound quality is very good. Typical load on CPU during playback is 25-35% with Amplifier.
Regards
Alma
-
Hello
Do any of you have a picture of how you have installed the mp3@64.
I have bougth the mp3@64 card but I havet def. accellerator card... So i'm waithing for a card from softhut.... Hope it comes soon...
Espen
-
Hi,
first thing I would do is to launch Scout, then the player, and check what causes the heavy CPU load.
Hope it helps
-
all the data has to be converted in software to serial for the I2C bus that the MAS chip requires.
MP3's down a 1-bit serial interface? I'm not sure what the Amiga parallel port is capable of, but I would imagine you could pre-process your MP3's into I2C files you can DMA.
For a fixed rate MP3 that could be 192Kbaud, what is the maximum rate of the Amiga parallel port?
-
Yeah, you probably could pre-process them, but that low level of stuff is kinda beyond me - once you start that you can't use the MHI driver and have to do all the timing and interrupts yourself, and I wanted it to be able to accept standard MP3 files from CF cards etc.
The parallel port itself is able to do it speed-wise for 192kbps files anyway, I don't have any trouble with that here. Possibly something to do with the clever trick the player does in clocking data on the leading and falling edge of the signal, thus saving half the number of pulses...
-
- Sometimes the sound is interrupted for a short period. Seems to be a bug
in the timer.device that sometimes causes interrupts to be delayed. I
tried very small intervals, but it still remained, so I guess it's either
a bug in timer, or the system interrupt load causes high latencies.
I might elaborate more on these problems. The original MAS Player by Dirk Conrad uses the parallel port to both send I2C commands and serially clocked mp3 data to the MAS-Chip (bitwise!). The first, old version even required two bits to send out one bit of MP3 data. Due to the internal parallel port being custom chipset register space, it is rather slow to access this space (like chipram).
The MAS Chip itself has a buffer of about 1 KB, if I remember it correctly. It has a pin that will report when the buffer is getting full and the sender should stop transmitting data, I think I may send up to ~250 bytes after this pin has changed. Unfortunately, the MAS Player design is a bit flawed in the sense that the change of the buffer full line is not connected to the _ACK pin that would allow interrupt driven data transfer. Instead, I have to constantly track the signal level of this pin before sending more data (I do this every ~250 bytes).
Due to VBR and the internals of this chip, it makes it hard to estimate the rate at which the buffer full line needs to be checked to avoid buffer underflows. I really tried a lot of different techniques, but in the end, I just had to make sure that the line is checked often enough and the current implementation uses a sliding interval that automatically adapts to the rate of the MP3. But this means that the driver causes many interrupts per second, thus requiring some CPU time (that you're unable to measure with Scout and such).
Now, let's look at the MP3@64. This device was designed to be operated in the C64 with Jens' custom build clockport there. Unlike the MAS Player, I can send the serial data bytewise, not bitwise, which would actually be much better, if not... well, the MP3@64 streams the bytewise data to the MAS Chip serially, *just like the MAS Player* and it uses a timing that the C64 is slow enough to write one byte after another without disturbing the serial transfer that is done by the logic in the background.
The Amiga however, is much faster. So while I had to write out the data bitwise to the parallel port on the MAS Player, I can write a full byte in one go, *but then I have to wait for a while* before I can send the next byte. Of course this wait is so short that it doesn't make sense to release the CPU to do something else. Hence, the MP3@64 needs more or less the same CPU time as the MAS Player.
And finally, the MP3@64 also doesn't connect the buffer full line to the interrupt 6 pin of the clockport, hence the polling of the overflow line is also the same there with the same problems described above.
Hence, you will need some CPU time to operate the MP3@64 or MAS Player, and the stutter will be less if you've got a faster CPU. You probably shouldn't be using high frequency interrupt sources like the internal serial port at the same time.
The stutter probably will be gone if somebody rewrites the interrupt code not to use the timer.device (more system conform), but the CIA chips directly. Jens has the code of the device, if I remember it correctly.
-
MP3's down a 1-bit serial interface? I'm not sure what the Amiga parallel port is capable of, but I would imagine you could pre-process your MP3's into I2C files you can DMA.
For a fixed rate MP3 that could be 192Kbaud, what is the maximum rate of the Amiga parallel port?
There's no DMA to the parallel port or serial port. Check your hardware documentation ;) The only DMA you could try would be audio (which is rather useless, as it's analogue) or disk (which might work, but then again, the data rate is pretty low here).
Moreover, the mp3 data is not sent via I2C. Only the control commands are send via I2C (such as volume control).
On the other hand, something probably hardly anybody knows: One CIA is used for barrel-shifting serial data from the keyboard. The second CIA also has this barrel-shifter (bidirectional) and it is connected to some lines on the parallelport. I'm fairly confident that this parallel to serial converter could have been used in the MAS Player design to speed up things, but unfortunately, it wasn't.
-
The parallel port itself is able to do it speed-wise for 192kbps files anyway, I don't have any trouble with that here. Possibly something to do with the clever trick the player does in clocking data on the leading and falling edge of the signal, thus saving half the number of pulses...
The trick with the rising and falling edge is exactly the difference between the normal and the later, Pro version of the MAS Player.
-
Thank you Chris for that good, concise explanation. It seems that there wouldn't be much benefit for me to switch to the MP3@64. Do you know why the interrupt isn't used? Or if it might be possible to modify the MP3@64 or the MAS player to use it? I guess then it would also need a new MHI library...
I am hoping to be able to use the internal serial port with my project, but it can be run at low speed (9.6k should be enough) as it's only used to update an LCD display and maybe receive IR remote codes in the future, so I don't think the interrupt load will be too high. If it is, do you think that could be improved by switching to the MP3@64?
-
Interesting stuff... didnt know there was no DMA to parallel port. Damn that's a bit of an oversight. I am sure there must be a technological reason why not.
-
Interesting stuff... didnt know there was no DMA to parallel port. Damn that's a bit of an oversight. I am sure there must be a technological reason why not.
A floppy port interface should at least be support DMA transfers from chip memory to whatever was dangling off the end of it. Not sure how easily it could be implemented though as the hardware will use MFM (http://en.wikipedia.org/wiki/Modified_Frequency_Modulation) encoding.
-edit-
I see Chris beat me to it :)
-
A floppy port interface should at least be support DMA transfers from chip memory to whatever was dangling off the end of it. Not sure how easily it could be implemented though as the hardware will use MFM (http://en.wikipedia.org/wiki/Modified_Frequency_Modulation) encoding.
-edit-
I see Chris beat me to it :)
The Amiga did no MFM encoding in hardware! IIRC that was all done by the trackdisk.device (Some one really should write a trackdisk.device with 8b/10b encoding):)
-
The Amiga did no MFM encoding in hardware! IIRC that was all done by the trackdisk.device (Some one really should write a trackdisk.device with 8b/10b encoding):)
Hmm, I thought there was something in Paula that did it. It's been a long time since I looked at this stuff :)
Assuming there is no hardware MFM, then even better. One less thing to worry about on the device end. You've got a DMA driven serial port that should be able to shift data at a high enough bitrate for a lot of mp3s...
-
Hmm, I thought there was something in Paula that did it. It's been a long time since I looked at this stuff :)
Assuming there is no hardware MFM, then even better. One less thing to worry about on the device end. You've got a DMA driven serial port that should be able to shift data at a high enough bitrate for a lot of mp3s...
Without meaning to disparage the old lady (25years isn't old!!!), she was a simple little beast... but that is why she was so flexible... I think the amiga could even read the weird Mac disk encoding schemes, with the right software... Näturlich...
-
Theoretically then, what's the show stopper for using the floppy port to send data to a device that expects to recieve serial information?
I always thought the floppy connector was an underutilised expansion port.
-
Theoretically then, what's the show stopper for using the floppy port to send data to a device that expects to recieve serial information?
I always thought the floppy connector was an underutilised expansion port.
I used to think the same... but now, it's just non-standard low speed serial port, which probably requires quite a bit of work to interface with... the clockport is simply easier and fast as it sits on the 68k's bus...
-
Interesting stuff... didnt know there was no DMA to parallel port. Damn that's a bit of an oversight. I am sure there must be a technological reason why not.
Probably because it requires additional logic to conditionally DMA stuff depending on the _ACK handshake signal of the printer connected to the parallel port. I don't think this line (or any other CIA line) is routed back to the DMA engine in the Agnus chip.
-
Thank you Chris for that good, concise explanation. It seems that there wouldn't be much benefit for me to switch to the MP3@64. Do you know why the interrupt isn't used? Or if it might be possible to modify the MP3@64 or the MAS player to use it? I guess then it would also need a new MHI library...
I am hoping to be able to use the internal serial port with my project, but it can be run at low speed (9.6k should be enough) as it's only used to update an LCD display and maybe receive IR remote codes in the future, so I don't think the interrupt load will be too high. If it is, do you think that could be improved by switching to the MP3@64?
It probably would need some sort of transistor or inverter gate. I haven't looked at the schematics for a long time. The interrupt wasn't used on the MP3@64 as it was specifically designed for the C64 and not for the Amiga.
9600 bits/sec is not a high load for the serial port. 115200 bits/sec surely is (and barely achievable).
-
Hmm, I thought there was something in Paula that did it. It's been a long time since I looked at this stuff :)
Assuming there is no hardware MFM, then even better. One less thing to worry about on the device end. You've got a DMA driven serial port that should be able to shift data at a high enough bitrate for a lot of mp3s...
I once wrote a device that would use 2bit -> 3bit encoding but it only worked reliably for the first 40 cylinders. That would have provided >2.5 MB/HD (32 sectors) or >1.2 MB/DD (16 sectors) disk. But I canceled the project because at that time (1998) already the use of floppy disks was dwindling.
The blitter was used to generate the MFM encoding (3 passes for bit splicing and remerging) and decoding (1 pass for merging).
I googled for nearly one hour to find the DMA speed of the floppy controller, but I wasn't successful. The closest estimate I can give is about this one: there are three DMA slots for disk and one slot for each audio channel. While at PAL the maximum replay frequency is about 28 KHz (2 samples per slot), and the disk DMA is supposed to transfer one byte per slot, I get a theoretical maximum speed of about 42 KB/sec for disk DMA.
(As the DMA assignment didn't change even with AGA, this is the reason why Amiga HD drives spin at half speed, because Paula cannot keep up the required data rate.)
-
... I get a theoretical maximum speed of about 42 KB/sec for disk DMA.
So, even if the achieveable rate were only half that, that's still >200Kbps. Sounds ample for our theoretical floppy port mp3 decoder :)
-
Hi all,
Here's the latest after i tried the MP3@64 in my A2000 with the Buddha card.
1st i installed all the needed software, then connected the MP3@64 to the Buddha. I then fired up the A2000. I was so excited during bootup that all was going ok, untill i saw a heap of smoke coming from the MP3@64. Man i fried the chip that sits in the middle of the MAS chip and the crystal. I must have had the orientation of the cable f*cked up. I plugged it in with the red line on the ribbon cable running the same way (Left) it did when i plugged it into my A1200. I guess i should have had the red line to the right of the card. At the time i also had the floppy power cable in the Buddha to power a 2.5" HD. That would not have caused the chip to fry would it???
Ok, this little incident isnt going to put me off from having my Amiga play MP3's in full 16 bit stereo sound as i am going to purchase another card. The question i have now, (i should have asked this 1st as it would have saved me $100) when i receive my new MP3@64, which way does the red line on the cable face on the Buddha. The HD cable has the red line on the ribbon cable facing to the right. Do i follow the same orientation as the HD cable and have the red line on the MP3@64 ribbon cable also facing right?? Also does the Red line on the ribbon stay the same (its to the left of the audio plugs facing away from the card) as it does when plugged in the A1200. or another way to ask so i dont confuse people as i am confusing myself as i write, does the cable that is attached to the MP3@64 stay the same on the card if it is used on an A1200 or a Buddha??
Cheers
-
Are you just loading the MP3 off an IDE HD from the internal IDE port? Maybe when you get the new MP3@64 try copying the MP3 to the RamDisk: and see if playing out of RAM makes any difference.
( I remember setting up my first 80meg HD back in '94 on my A1200 and had a hell of time with the Transfer Mask (I think) setting. Had to change it something like 0xfffffffff.... When the HD was first set up any single file that was over 128k got corrupted, HD was slow, etc.. That is obviously a totally difference simpton, but maybe could be something with the HD transfer??)
I was also unable to get my ethernet adapter to work through the credit card slot as i was told my mobo also needed a mod done because the port would not reset with the given software. I was unable to connect to my router so i ended up selling the ethernet card. Not all A1200's suffer from these above mentioned issues...
I had similar problems with my A1200 and PCMCIA ethernet card back in the day. There are two programs from Aminet that did the trick for me...
CardPatch.lha
CardReset.lha
As far as I know these basically replaced the need for the hardware patch the PCMCIA needed.
Good luck.
-
So, even if the achieveable rate were only half that, that's still >200Kbps. Sounds ample for our theoretical floppy port mp3 decoder :)
Why not off the joystick port? I hear the Amiga joystick ports are fast. ;-)
-
Why not off the joystick port? I hear the Amiga joystick ports are fast. ;-)
:roflmao: :roflmao: :roflmao: :roflmao: :roflmao: +1 :D
-
@AmigaNut08
Ouch! Yeah, the clockport (and its clones) have access to the +5V line which is only restricted by what the traces can carry, so it's very easy to burn things out! Does the Buddha card not have a mark showing which end is pin 1? Even this howevr isn't a good indication... From the Amiga Hardware Database: (http://amiga.resource.cx/exp/buddhaphoenix)
- when installed in Zorro slot, pin 40 of the card's clock port is towards the front side of the computer, pin 19 resp. pin 1 towards the rear side
- marked wire of clock port expansions go to pin 19 or pin 40, depending on the manufacturer's definition - e.g. expansions made by Individual Computers are installed with the red stripe on pin 40 (to the left), expansions of E3B mark pin 19 / pin 1 (to the right)
Having the floppy connector plugged in wouldn't have caused this, but it might have prevented damage to the motherboard/Buddha card by not pulling all that power through them - depending on their design of course.
-
Hi,
There is a mark showing pin 1 on the 2 ide connectors on the Buddha card but i dont think there was an indicator showing pin 1 on the clockport connector.
Well luckily the Buddha card is still ok as i am using it with a HD connected to it.