sethmachine / universal-sound-board Goto Github PK

This is tricky because we need to spin up a fresh database when unit testing each DAO.

This is to support an action where a user plays an audio clip for their audience but the user also wants to hear the same audio clip played back to them.

While the current API does offer a basic functionality to do this, it would result in slightly out-of-sync audio playing to different outputs, and it would require uploading the same file at least twice.

One solution is to create a new resource specifically for coordinating these complex actions. The action accepts the following inputs:

• sourceId of the device used as the in-app microphone (this plays the audio clip through the application's "microphone")
• sourceId of the user's actual speakers or audio output (the device they use to listen to their sound)
• the audio file
• optionally, the sink ID of the actual microphone so it can be "muted" to prevent any echoes/feedback.

A single audio input stream (or 2?) can be created from the single file upload. Then using the source's thread pool executor, simply play the audio clip to both sources.

If muting the user's microphone is a requirement, the flow might look like this:

• Use API to stop the sink device completely (i.e. mute microphone)
• Simultaneously play the audio clip to 2 or more sources
• Start the sink device again (i.e. unmute microphone)

Should muting/unmuting be part of the complex action, or should the caller have to mute/unmute the microphone themselves?

When playing audio files to a source, if the audio formats do not match, then the sound will be distorted/sped up/slowed down depending on the differences in framerate, etc. Or it's possible you get a sound file that is little endian but the source is big endian--this usually makes the sound file incomprehensible.

Steps forward:

• See if it's possible to reformat incoming audio files if they don't match the source's audio format
• Provide an optional parameter that allows users to control whether they want the format to match the source format (default should be true)

There appear to be a lot of audio formats for audio devices where many of the fields are unspecified, e.g.

            "audioFormat": {
                "encoding": {
                    "name": "PCM_SIGNED"
                },
                "sampleRate": -1.0,
                "sampleSizeInBits": 24,
                "channels": 1,
                "frameSize": 3,
                "frameRate": -1.0,
                "bigEndian": true
            },

It's unclear why one would use these formats over formats where all the fields are specified. For now, it may make the API easier to consume by filtering out any formats with unspecified fields.

Many properties of the server are currently hardcoded in the yaml.

These include:

• port the server runs on
• directory of where the derby database is written
• etc.

Currently you can keep starting the same sink even if it's running, e.g. this curl request can be executed again and again without issues:

curl -X POST -H "Content-Type: application/json" localhost:8080/sinks/start --data '{"sinkId": 1}'

While it doesn't seem to break functionality, it creates a new thread for each sink and is wasteful.

Similarly, you can stop sinks that aren't running.

Suggested solution is to introduce a new SQL table, AUDIO_MIXER_STATE that has a row describing the current state of any active (or inactive) audio mixers. It could be re-used for both sinks and sources (e.g. you play an audio clip to a source but you decide you want to stop it).

Update the README so it is a publicly facing document that provides a high level overview of the project and how to use it.

This will enable creation of artifacts like a compiled JAR automatically.

Try following the guide here: https://docs.github.com/en/actions/automating-builds-and-tests/building-and-testing-java-with-maven

We should use sane defaults when dealing with NOT_SPECIFIED: https://docs.oracle.com/javase/7/docs/api/javax/sound/sampled/AudioSystem.html#NOT_SPECIFIED

In the future we can allow users to specify these when playing an audio mixer.

There are no unit tests for anything. We can begin writing unit tests for non-DAO classes as they don't require a temporary database to stand up (as you mock out the DAO responses).

There's no way to delete any audio mixers or wirings saved to the embedded derby DB.

Once audio is played to a source it cannot be stopped unless the server is shutdown.

This adds a new stop functionality that allows stopping a source from playing audio if it hasn't finished playing yet.