I'm hoping to create a system which can drive up to 32 speakers for US$300. The system is intended for playback of high-quality, pre-recorded media but would also be suitable for highly lossy streaming. Where a client is able to prioritize data retrieval, it is possible to sacrifice three dimensional sound then two dimensional sound then one dimensional sound (stereophonic) before sacrificing frequency response of zero dimensional sound (monophonic). This provides the most immersive experience with the least bandwidth. In favorable circumstances, only 5% of the data is critical and this may survive in an environment of 70% packet loss. This is far outside the range of TCP window-scaling which has become the favored distribution mechanism of multi-national corporations (and those who would emulate them).
After gatheringrequirements and devising a specification, I expect to receive a clone Arduino Due and five Microchip MCP4921 12 bit SPI DACs. The former is likely to irritate me and the latter will sound horrible; especially if they only bias a speaker in one direction. However, this is sufficient for testing. Assuming I don't destroy more hardware, I'll have enough hardware to test a five speaker, 3D surround sound system. Assuming hardware doesn't wear at an alarming rate, I expect to have something working by Sep 2017. Unfortunately, such an estimatemay be optimistic. Although suitable hardware is not expected within the next 10 days, software development can begin.
I don't have a 3D recording system and so test data is going to be extremely limited. It is likely to be a batch conversion from monophonic or stereophonic WAV to Ambisonic WXYZ format implicitly held in a quadraphonic WAV. Conversion may perform effects such as soundstage rotation. This would be followed by a stub implementation which streams a quadraphonic WAV to an Arduino. And how will this be achieved? Well, it definitely won't integrate as a sound device which inter-operates with a host operating system. (If your operating system doesn't already support sound-fields then such integration will, at best, present a two dimensional 7.1 interface but is more likely to appear as a stereophonic device.) It is likely that the Arduino won't appear as a dedicated USB device. From documentation, it appears that the interface will be a virtual serial port over USB. This may be sufficient for testing but it won't be suitable for deployment.
In the general case, few liberties can be taken with a virtual serial port and therefore extensive framing of data is required. It can be assumed that transfers are contiguous up to 512 bytes. However, this may be more apparent to a device using Serial::readBytes() rather than a host using POSIX read(). The majority of data is transferred from host to device and it may be possible to relax framing constraints in this direction only. In the most paranoid case, it may be preferable to send bit-stuffed, fixed-length cells in both directions. However, this greatly increases processing load at both ends. Thankfully, it isn't required to also be DC-balanced. From a failed venture, I already have rights to tested code which performs this function.
Average Quality Audio, Part 5
(This is the 19th of many promised articles which explain an idea in isolation. It is hoped that ideas may be adapted, linked together and implemented.)
I'm hoping to create a system which can drive up to 32 speakers for US$300. The system is intended for playback of high-quality, pre-recorded media but would also be suitable for highly lossy streaming. Where a client is able to prioritize data retrieval, it is possible to sacrifice three dimensional sound then two dimensional sound then one dimensional sound (stereophonic) before sacrificing frequency response of zero dimensional sound (monophonic). This provides the most immersive experience with the least bandwidth. In favorable circumstances, only 5% of the data is critical and this may survive in an environment of 70% packet loss. This is far outside the range of TCP window-scaling which has become the favored distribution mechanism of multi-national corporations (and those who would emulate them).
After gathering requirements and devising a specification, I expect to receive a clone Arduino Due and five Microchip MCP4921 12 bit SPI DACs. The former is likely to irritate me and the latter will sound horrible; especially if they only bias a speaker in one direction. However, this is sufficient for testing. Assuming I don't destroy more hardware, I'll have enough hardware to test a five speaker, 3D surround sound system. Assuming hardware doesn't wear at an alarming rate, I expect to have something working by Sep 2017. Unfortunately, such an estimate may be optimistic. Although suitable hardware is not expected within the next 10 days, software development can begin.
I don't have a 3D recording system and so test data is going to be extremely limited. It is likely to be a batch conversion from monophonic or stereophonic WAV to Ambisonic WXYZ format implicitly held in a quadraphonic WAV. Conversion may perform effects such as soundstage rotation. This would be followed by a stub implementation which streams a quadraphonic WAV to an Arduino. And how will this be achieved? Well, it definitely won't integrate as a sound device which inter-operates with a host operating system. (If your operating system doesn't already support sound-fields then such integration will, at best, present a two dimensional 7.1 interface but is more likely to appear as a stereophonic device.) It is likely that the Arduino won't appear as a dedicated USB device. From documentation, it appears that the interface will be a virtual serial port over USB. This may be sufficient for testing but it won't be suitable for deployment.
In the general case, few liberties can be taken with a virtual serial port and therefore extensive framing of data is required. It can be assumed that transfers are contiguous up to 512 bytes. However, this may be more apparent to a device using Serial::readBytes() rather than a host using POSIX read(). The majority of data is transferred from host to device and it may be possible to relax framing constraints in this direction only. In the most paranoid case, it may be preferable to send bit-stuffed, fixed-length cells in both directions. However, this greatly increases processing load at both ends. Thankfully, it isn't required to also be DC-balanced. From a failed venture, I already have rights to tested code which performs this function.