Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Looking for a ASIO driver developer (Read 1827 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Looking for a ASIO driver developer

We are a high-end audio manufacturer, PS Audio, and building a recording studio based on DSD. We need to get 32 channels of DSD into a Windows computer either in DoP or natively.

If there are any developers familiar with this requirement that would consider working with us please reach out

What is needed is a system for connecting multiple channels (32 minimum) of DSD128 audio into a Digital Audio Workstation, operating on the Windows 10 OS, using ASIO.

There are consumer solutions for DSD audio over USB, but they are limited to 2-8 channels. Pro audio equipment supports higher channel counts, but are generally limited to PCM only. Ravenna networked audio can in theory support DSD but the currently available OEM hardware does not.

The source equipment (A/D converter) is being designed by PS Audio and we have great flexibility on how the digital audio is transmitted. We have interfaces for SDIF, AES-3, MADI, Dante, and Ravenna.

Proposed Solution:
   The likely solution is to use a format known as DoP, or DSD Over PCM. In this format, 16 bits of DSD audio information are encoded into a 24 bit PCM frame. The remaining 8 bits are used for a flag sequence that receiving hardware and software can recognize. The flags and bit order are chosen such that this signal is benign if played back on a non-DSD aware receiver.
   
Standard “Single Rate” or 64x DSD encodes 64 bits for every 44.1KHz sample period (2.8224Mbps). With 16 bits encoded per frame it takes 4 frames to encode 64 bits. Thus the PCM frame rate required for DSD64 is 176.4KHz. Most pro audio interfaces will support 176.4KHz PCM.
   
“Double Rate” or 128x DSD encodes 128 bits for every 44.1KHz sample period. In order to use DoP encoding a 352.8KHz PCM frame rate would be required. Few interfaces support this rate, so there is also an option to use two 176.4KHz frames (2 PCM channels) to encode DSD128.
   
(We are currently only interested in Double Rate, but “Quad Rate” and “Octal Rate” exist and could theoretically be encoded in 4 or 8 channel frames at 176.4KHz PCM)

Proposed Implementation:
   The solution would be a software driver that either replaces the standard hardware driver or is able to exist “on top of” the standard driver or “in between” the existing driver and the application. For each audio channel, this software would need to receive one or more channels of PCM audio data from the ASIO hardware interface, decode it into a DSD audio, and make that available to an ASIO application.
   
For example, Audinate (Dante) PCIe-R soundcard (https://www.audinate.com/products/manufacturer-products/dante-pcie-card)
Can receive 64 channels of 176.4KHz, 24 bit PCM data. Software/Driver would receive these 64 channels of PCM data, convert them to 32 channels of DSD128 data, and make that available to the application.

Re: Looking for a ASIO driver developer

Reply #1 –
Probably best to put a job advert out, either on your website or with a contracting agency. How much are you paying?
 

Re: Looking for a ASIO driver developer

Reply #2 –
Thanks. I was hoping this forum would be a good place. Problem with just posting a job advert is we would have to fully document the job and task, something we don't know enough about to do. Which is part of the problem. We know what we want in the end. We don't know how to craft a detailed RFQ.

Re: Looking for a ASIO driver developer

Reply #3 –
Quote from: psaudio on
Thanks. I was hoping this forum would be a good place. Problem with just posting a job advert is we would have to fully document the job and task, something we don't know enough about to do. Which is part of the problem. We know what we want in the end. We don't know how to craft a detailed RFQ.
Paul, is that you? :)