The question of sound #11

Closed
opened 2025-04-09 15:00:06 +00:00 by tcsenpai · 0 comments
Owner

Originally created by @JanNeuendorf on 12/19/2024

Before the specifications are finalized, there is one important question left to answer.

Is it okay,that this system will never have sound?

I wanted to write out my thoughts on this, just in case someone sees this and wants to discuss it.

The big argument for having no sound output is of course simplicity.
Every emulator can output no sound correctly.

For someone writing stuff for the system, sound adds an additional layer of complexity while arguably not offering much of learning opportunity. At least not in the same way as drawing to a screen does.

But having no sound is a big sacrifice so it must be considered carefully.

If one wanted to add sound, what would be the possible ways to do this while changing the system as little as possible?
Two constrains I would have here are:

  • No real changes to the instruction set. (But we can assign meaning to an unused argument.)
  • No communication between the virtual computer and the system emulating it should be required in between frames.

The second point is a big deal for sound. The sound that is played could only be updated every frame. What could this sound be?

Idea1 A simple beep

It could just be a beeping sound that could be triggered with the sync instruction. Maybe there could be a list of levels like: beep, warning, loud warning etc. and it is left to the implementation what that means.

Idea2 Fixed Waves

There could be a list of frequencies of sine- or square-waves that can be activated. This would require some format to be invented. It might be very difficult to fit this into a single u16.

Idea3 A buffer for Sound

There could be a buffer for the raw amplitude of the sound that is played every frame.
There are a bunch of problems with this:

  • One of the nice things about the system is that screen and memory are the size of the address space. I would not want to give that up. So a sound buffer would be as large as the screen, which is way to big.
  • A sound curve oscillates around zero and there is no native format for negative numbers (or floats).
  • The system is probably not fast enough to generate a sine wave.
*Originally created by @JanNeuendorf on 12/19/2024* Before the specifications are finalized, there is one important question left to answer. > Is it okay,that this system will never have sound? I wanted to write out my thoughts on this, just in case someone sees this and wants to discuss it. The big argument for having no sound output is of course simplicity. Every emulator can output no sound correctly. For someone writing stuff for the system, sound adds an additional layer of complexity while arguably not offering much of learning opportunity. At least not in the same way as drawing to a screen does. But having no sound is a big sacrifice so it must be considered carefully. If one wanted to add sound, what would be the possible ways to do this while changing the system as little as possible? Two constrains I would have here are: - No real changes to the instruction set. (But we can assign meaning to an unused argument.) - No communication between the virtual computer and the system emulating it should be required in between frames. The second point is a big deal for sound. The sound that is played could only be updated every frame. What could this sound be? ### Idea1 A simple beep It could just be a beeping sound that could be triggered with the **sync** instruction. Maybe there could be a list of levels like: beep, warning, loud warning etc. and it is left to the implementation what that means. ### Idea2 Fixed Waves There could be a list of frequencies of sine- or square-waves that can be activated. This would require some format to be invented. It might be very difficult to fit this into a single u16. ### Idea3 A buffer for Sound There could be a buffer for the raw amplitude of the sound that is played every frame. There are a bunch of problems with this: - One of the nice things about the system is that screen and memory are the size of the address space. I would not want to give that up. So a sound buffer would be as large as the screen, which is way to big. - A sound curve oscillates around zero and there is no native format for negative numbers (or floats). - The system is probably not fast enough to generate a sine wave.
Sign in to join this conversation.
No Label
No Milestone
No project
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: github/SVC16#11
No description provided.