Seeking qualified, experienced developers

We are a highly respected US audio manufacturer seeking a qualified, experienced individual who can design for us the software, hardware and firmware to accomplish the following 2 tasks:

TASK 1. Start with .WAV files 16 bits, 44.1KBPS organized as ALBUMS with names and TRACKS with names. These files originate from CD's or other audio sources and are stored on SDHC cards. Up to 60 such ALBUMS on a 32GB SDHC card.
The output will be only I2S 4 wires: SERIAL DATA, WORD CLOCK, BIT CLOCK and GROUND.
We will provide all the power, regulators, displays, control switches but you provide the interfaces, preferable using standard 0.1' spaced headers, with which we interface.

Provide a PCB(s) with all harware software firmware to interface with external power and regulators, display of album and track descriptions and for control switches. If iinteredsted we will supply more detail and also willing to talk on the phone.

TASK 2: Associated with the device above, but as an off-line process, we need a friendly way to rip CD's using iTunes or other readily available software. iTunes is not friendly for .WAV format. For .WAV you must rip one CD at a time, create a file (ALBUM) and manually associate that file with the tracks for that CD. We'd like our customers to be able to have that process automated so they can load a bunch of CD's into their MACs or WINDOWS machines and drag .WAV formatted ALBUMs into an SDHC card and have the album/track data remain associated with the original CD be available for reading and displaying on the device above via the SDHC card.

We are in the Washington DC and Berkeley Springs WV areas so if you are within driving distance of that area great, but can do business with anyone qualified who wants to work with us. if interested we will send you an RFQ (Request for Quotation).

Why *.wav ?
And which display ?

.WAV has the sound quality we need.

We are currently using a NEWHAVEN NHD-0216SZ-FSW-FBWbut we are open to suggestions. An important requirement: the display even though it will be located several feet away from the device, interferes with the sound and we must give the user a switch to turn off the LED backlight and separately the power for the LCD.

Task#1 should be easy to do with the Teensy 3.2. If you wait for Teensy 3.6 (available in 2..3 Month ??) you could use ".flac" which is more itunes-friendly (flac needs more RAM than T3.2 has available) - other formats are possible, too.
I think your display works with the standard-libraries, too.

Thanks for the response: are you interested in responding to our RFQ?
We are in the high end audio business where every little detail contributes - for better or for worse- to the sound. We even heard a difference between the same track of the same CD ripped with iTunes vs EAC, both 16 bits, 44.1KSPS and both .WAV.
We had a panel of 3 critical listeners in a double blind test and all preferred the iTunes rip even though it had 308 fewer bits out of 50 MB. Wish I could explain why but that is the world of hi end audio. We'd have to listen to the same CD ripped with .WAV then with .flac to make a determination. But if we can arrange a test we're open to trying the .flac.

Flac is lossless, so there is no difference , regardless what any audiophiles say.. after decompression, it is identical with wav.
It works with the teensy 3.2 but with only with smaller block-sizes (non-std)

Re: RFQ, i'm interested, but i dont have much time..
On the other side, its not too much work, i think..

Let's assume we'll stick with .WAV for the time being: we already have ripped several hundred CD's using iTunes, a painful process but a large investment we'd like to maintain.

Here is the RFQ we'd like qualified individuals to bid on:

We are total analog guys and gals here and have no time to divert to learning Arduino. We are looking to work with a competent party who can interpret our specs, ask questions to clarify, give us a price for the first board(s). Then we would want a quote for 10 boards at a time.

Your initial risk would be to consider our specs, estimate your time for the non-recurring and the first working prototype and to get us to where you can quote the cost of that initial effort and then 10 copies. There may also be some refinement effort after we buy the non-recurring and the first board (boards?) but that would be separately priced. We would not ask you to do any design engineering without getting paid.

The name of our project is the MAXWELL DIGITAL JUKEBOX.

It's ONLY purpose is to play audio CD's ripped at 44.1KBPS, 16 BITS, .WAV formatted and to output the audio into a 4 pin I2S header (0.1" pin spacing and with a basic set of human machine interfaces.The MAXWELL DIGITAL JUKEBOX is a standalone file player and is not connected to any external device (no laptops). It is not designed to play downloads from the internet unless they are separately created offline and put into .WAV format then placed in the SDHC card. We will supply the chassis, power, display, controls. You supply the basic non-recurring engineering, SDHC-i2S engine and its in ports, preferably in the form of 0.1" spaced headers.

Here is a first order list of our requirements just to give you an idea of what we are looking to have priced:
You provide us the PCB's meeting the following specs:
1. Boards each have 4 mounting holes
2. The size of the boards should not exceed 160mm x 100mm x 75mm high. We have some flexibility if that is too constraining.
3. All major circuits should be powered externally through standard 0.1" spaced headers so we can connect our pure power supplies. We prefer not to use any on- board regulators if that can be avoided . Our preferred voltages are multiples of standard D cells: they range from 1.5 to 1.6 V per cell. So we typically provide nominal 3V to 3.2V or 4.5V to 4.8V , etc
4. The oscillator(s) are to be separately powered and not share a bus with anything else.
5. The SDHC socket has its own power bus
6. MEMORY has its own power bus
7. FPGA has its own power bus
8 Microprocessor has its own power bus
9. If the I2S has some sort of chip it too should have its own power bus
10. Once we see the layout and schematic we may ask for additional dedicated power buses
11. Input is through a standard SDHC card slot that accepts up to 32GB SDHC 40 MBPS (or higher) cards (we'll send you some of the cards that we have evaluated to be sure they are compatible with your selection of card reader).
12. Output is !2S through a 4 pin standard header with 0.1" pin spacing. We do NOT want SPDIF, HDMI or any other output for the digitized audio. I2S pin- out: PIN 1 BIT CLOCK, PIN 2 WORD CLOCK, PIN 3 DATA, PIN 4 GROUND. Clock should be native and NOT upsampled or multiplied.
13. We need to display the selected ALBUM NAME, the selected TRACK number and upon startup we want to display the words:
MAXWELL DIGITAL JUKEBOX for a few seconds. We also want to display the mode. And if an error is detected. the display should say RESTART or else a separate ERROR light can be provided.
Also the selected ALBUM NAME, and TRACK NAME and TRACK #.
14. MODES; the user needs to be able to select ALBUM JUMP or TRACK JUMP. Also the user needs to be able to select REPEAT ALL or NO REPEAT or REPEAT TRACK. You must create the capabiity to support these modes
15. Separate switch headers can be provided and we will supply the actual toggle switches to select each mode. You would create the software and firmware for the modes.
16. We plan to use the Newhaven Display NHD-02126SZ-FSW-FBW. We supply the display. You supply the 16 pin header to drive it. We provide power for the LED and the display.
17. We need to be able to control the power to the display's LED backlight and also and independently control the power to the display proper without interfering with the musical playback modes or the music itself when playing.
18. CONTROLS: in addition to the mode controls, we need the following functions: PLAY, STOP, FORWARD, BACKWARD.
19. FORWARD and BACKWARD interact with the modes so that when the user presses FORWARD and the mode is ALBUM JUMP the player selects the next album or if in TRACK JUMP mode the player selects the next track within the album. If the user presses BACKWARD the player selects the previous ALBUM or TRACK depending on mode..
20. Time constants shall be optimized for 44.1KSPS 16 BIT .WAV formatted music files organized by ALBUM NAME. When playing sequential tracks within an album, some classical albums have very short gaps between movements (tracks). This is too complicated to spec without a conversation but it is a challenge that many file players have not solved.. When the time between tracks in a given album are very short, file players can lose the first fraction of a second of music on the next track. That is a problem we would like to address and solve.


On a related subject if you have ever tried to rip a CD using iTunes you'll run into a very awkward set of steps that APPLE has not really addressed. i spent 2 hours with their tech support people only to find out that they really aren't properly set up for .WAV format. iTunes losses all relationship between album names and the track numbers for .WAV files. So you have to rip no more than 1 album at a time or else all the tracks get mixed up within iTunes. If you can solve this problem we would be happy to discuss costs separately.