3

I'm currently trying to figure out a way to loop sound (currently present in mp3/wav format) in bootloader code, but I don't have a clue where to start at.

Therefore I got 3 questions:

  1. Is it easier to play some sound when the processor is in 16-bit mode, or in 32-bit mode?
  2. Which format for the sound would be the best?
  3. Is there any public avaliable library for that? I haven't found anything useful. (Maybe I'm blind? Idk)

Thanks in advance^^

Bertrand Martel
  • 42,756
  • 16
  • 135
  • 159
  • I guess it starts by knowing what you mean by bootloader, some bootloaders are full blown operating systems which kinda defeats the purpose. At the end of the day though if you are bare metal then you need to be worrying about the audio device(s), and how to feed them 16/32 doesnt necessarily matter. Which format, the less overhead the better, mp3 has a relative large overhead unless the hardware decodes it directly then it gets pretty easy. otherwise a format with the most raw data. Libraries for all of it, are there, what is it you cant find. – old_timer Mar 12 '17 at 16:14
  • 3
    If you are really trying to do this within a boot loader under EFI or BIOS, you are biting of a very difficult problem. You effectively need to create sound card drivers, detect which sound card is available (if any) and then use the driver that you have written to access the card to play the sounds you want... unless you're just trying to beep the speaker.. that's not too hard. – David Hoelzer Mar 12 '17 at 16:26
  • If you're only trying boot off a real modern computers you can get away with only writing code (effectively a driver as David Hoelzer said) to access an AC'97 sound device. When using an emulator you might need to write code for accessing a SoundBlaster 16 card instead. Finding library code for decoding MP3s isn't hard but you'll need to adapt it for a bare metal environment where even basic things like `malloc` aren't available unless you code them yourself. – Ross Ridge Mar 12 '17 at 20:42

1 Answers1

3

Is it easier to play some sound when the processor is in 16-bit mode, or in 32-bit mode?

It makes little difference, mostly depend on the sound card you are trying to target - modern sound cards will require you to be able to address anywhere in the first 4GiB.
Putting the CPU into unreal mode would be the best - it is easy, gives you access to 4GiB address space and let you use the BIOS services.

Which format for the sound would be the best?

You can take a look at the MP3 page on Wikipedia to see that even before entering the technical details, the MP3 decoding is a very lengthy topic.
It presumes the knowledge of the Fourier series so you must be proficient in complex analysis (in the sense that involves complex numbers - the theory itself is a basic tool) and signal processing.
If you never heard of "sampling", "window function", "quantization" at all then it is time to read an handful of undergraduate books.
Of course you must be proficient with handling binary data, a picture or a table of the fields should be enough for you to write down the code.
An MP3 must be decoded into a series of samples.
Some card support decoding in hardware, I suppose (I never really checked).

The WAV file format is much easier - to the point that most file have the same fixed header (or you can support only that).
It is basically made to be played almost straightforwardly - if you settle on the sampling rate, bits per channels etc and produce wav files with only the minimal chunks you can even just seek into a specif offset and stream the data directly to the card.
The WAV format is already a sequence of samples if no compression is used.

Is there any public avaliable library for that? I haven't found anything useful.

Of course not, why there would be?
Some open source project to decode MP3 surely exists, it's not SO duty to point them out for you, but of course none will be targeted for the x86 boot environment.
You need to port it - and it may not be trivial.
Starting from finding a compiler that support real mode ending with implementing the minimal CRT needed.


Thing you also need to be proficient in:

  • IRQ
  • DMA
  • PCI / PCI-E
  • IO and MMIO
  • Read from disk

Now that you know the titanic effort needed, here some advises:

  • Have you considered the old speaker?
    You can only generate square waves (it's either on or off, a 1-bit "audio card") pretty much like the Game Boy.
    It may be good to warm up since it still require timing your code.
  • You can program the SB16 relatively easy.
    The SB16 is old, so it's simpler that modern cards.
    DOSBox can emulate it.
    I once wrote an answer on how to play a WAV file with such card under DOS.
    You just need to port it.
  • If you want to use a modern card find out the ones present in your system.
    There may be two since most Intel chipsets ship with one.
    The Intel datasheet for their chipsets always document the Intel Integrated HD Audio PCI device.
    Other cards may have proprietary datasheets - finding them is 90% of the work.
  • Test inside a VM
    This will spare you from innumerable reboots.

I'm not trying to scary you, playing sound or in general multimedial content in assembly is something marvelous and you should not desist but beware that it is a non trivial amount of work that assumes proficiency in assembly.
If you were looking for a quick and dirt solution then it's better to desist.
It's up to you to judge your self and decide the best course of actions.

CL.
  • 173,858
  • 17
  • 217
  • 259
Margaret Bloom
  • 41,768
  • 5
  • 78
  • 124
  • Ugg... please don't recommend anyone use unreal mode. It's far from easy. It's hard to get right and not worth the hassle. If you can switch to protected mode and back you can just do whatever you need to do much more easily in protected mode. – Ross Ridge Mar 12 '17 at 20:33
  • @Ross, why it's hard? I know every update to the segment registers must be avoided but I've used it and found it easier than switching back and forth between pm and rm. – Margaret Bloom Mar 12 '17 at 20:40
  • You have to switch back and and forth between them to enable unreal mode anyways, so as I said, you might as well just do whatever you need to do in unreal mode in protected mode. There's a reason why almost no one used it back in the day (HIMEM.SYS and Ultima VII the only serious examples I know of), it just wasn't worth the hassle. And remember you're an x86 assembly language expert. It might be easy for you, but for the average novice assembly language programmer playing around with bootloaders it's a herculean task. – Ross Ridge Mar 12 '17 at 20:58