Audi A6 C6 2010 MOST 44.1Khz

MOST
1

Hi Rhys,

After 1 year of buying the HAT, I’ve tested the USB C HAT board in my Audi A6 (C6 2010). I could see the Pi locked on to the MOST using legacy driver at 44Khz.

pi@raspberrypi:~/SocketMost/examples $ LOG_LEVEL=debug node server.js
05:29:17.245 - SocketMost-info: config file exists: {“version”:“1.0.0”,“nodeAddress”:272,“groupAddress”:34,“freq”:44,“mostExplorer”:true}
05:29:17.301 - SocketMost-warn: couldn’t unlink socket, might not exist already
05:29:17.307 - SocketMost-info: creating driver nodeAddress 0x110 groupAddress: 0x22 freq: 44
05:29:17.333 - OS8104 Driver-info: GPIO config: {“interrupt”:5,“fault”:6,“status”:16,“mostStatus”:26,“reset”:17}
05:29:17.438 - OS8104 Driver-info: starting up
05:29:17.440 - OS8104 Driver-info: resetting
05:29:17.443 - OS8104 Driver-debug: writing reset
05:29:17.445 - OS8104 Driver-debug: waiting reset
05:29:17.450 - SocketMost-info: most explorer enabled, starting server…
Listening for Most-Explorer requests on 0.0.0.0:5555
05:29:17.515 - OS8104 Driver-debug: stopping reset
05:29:17.538 - OS8104 Driver-debug: SCK configured
05:29:17.539 - OS8104 Driver-info: initial reset complete carrying out init
05:29:17.540 - OS8104 Driver-debug: removing all interrupts
05:29:17.543 - OS8104 Driver-info: running config
05:29:17.545 - OS8104 Driver-info: current network status is up setting output suitably
05:29:17.548 - OS8104 Driver-info: pin mode status: 0
addressLow: 0x10 addressHigh: 0x1 groupAddress: 0x22
05:29:17.551 - OS8104 Driver-debug: writing registry: 85 with value: f
05:29:17.554 - OS8104 Driver-debug: writing registry: 8a with value: 1
05:29:17.555 - OS8104 Driver-debug: writing registry: 8b with value: 10
05:29:17.558 - OS8104 Driver-debug: writing registry: 89 with value: 22
05:29:17.560 - OS8104 Driver-debug: writing registry: 83 with value: 0
05:29:17.562 - OS8104 Driver-debug: writing registry: 8d with value: 3
05:29:17.565 - OS8104 Driver-debug: writing registry: 92 with value: 2
05:29:17.568 - OS8104 Driver-debug: writing registry: 80 with value: 63
05:29:17.570 - OS8104 Driver-debug: writing registry: 82 with value: d3
05:29:17.571 - OS8104 Driver-debug: writing registry: 8c with value: 40
05:29:17.573 - OS8104 Driver-debug: writing registry: 81 with value: 50
05:29:17.574 - OS8104 Driver-debug: writing registry: 88 with value: 7
05:29:17.577 - OS8104 Driver-info: running in Legacy mode
05:29:17.579 - OS8104 Driver-info: register bXCR c
fault 0
05:29:17.592 - OS8104 Driver-debug: checking for lock
05:29:17.594 - OS8104 Driver-debug: lock status: 0x40
05:29:17.595 - OS8104 Driver-debug: pllLocked: 0
05:29:17.597 - OS8104 Driver-debug: Lock Source: 0
05:29:17.598 - OS8104 Driver-warn: locked
05:29:17.776 - OS8104 Driver-debug: message received
05:29:17.781 - OS8104 Driver-debug: MOST message parsed: {“type”:1,“sourceAddrHigh”:1,“sourceAddrLow”:0,“fBlockID”:1,“instanceID”:1,“fktID”:1,“opType”:1,“telID”:0,“telLen”:1,“data”:{“type”:“Buffer”,“data”:[160,0,0,0,0,0,0,0,0,0,0,0]}}
05:29:17.923 - OS8104 Driver-debug: message received
05:29:17.927 - OS8104 Driver-debug: MOST message parsed: {“type”:1,“sourceAddrHigh”:1,“sourceAddrLow”:0,“fBlockID”:1,“instanceID”:1,“fktID”:0,“opType”:1,“telID”:0,“telLen”:0,“data”:{“type”:“Buffer”,“data”:[0,0,0,0,0,0,0,0,0,0,0,0]}}
05:29:18.426 - OS8104 Driver-debug: message received
05:29:18.430 - OS8104 Driver-debug: MOST message parsed: {“type”:2,“sourceAddrHigh”:1,“sourceAddrLow”:0,“fBlockID”:1,“instanceID”:0,“fktID”:4,“opType”:0,“telID”:0,“telLen”:2,“data”:{“type”:“Buffer”,“data”:[3,255,0,0,0,0,0,0,0,0,0]}}
05:29:18.437 - OS8104 Driver-debug: message received
05:29:18.441 - OS8104 Driver-debug: MOST message parsed: {“type”:2,“sourceAddrHigh”:1,“sourceAddrLow”:0,“fBlockID”:2,“instanceID”:1,“fktID”:2560,“opType”:12,“telID”:0,“telLen”:1,“data”:{“type”:“Buffer”,“data”:[3,0,0,0,0,0,0,0,0,0,0]}}
05:29:18.442 - SocketMost-info: MOST master found from os8104 {“eventType”:“masterFound”,“instanceID”:1,“sourceAddrHigh”:1,“sourceAddrLow”:0}
05:29:18.451 - OS8104 Driver-debug: message received
05:29:18.454 - OS8104 Driver-debug: MOST message parsed: {“type”:2,“sourceAddrHigh”:5,“sourceAddrLow”:25,“fBlockID”:6,“instanceID”:255,“fktID”:1,“opType”:0,“telID”:0,“telLen”:5,“data”:{“type”:“Buffer”,“data”:[1,5,25,13,1,0,0,0,0,0,0]}}
05:29:18.463 - OS8104 Driver-debug: message received
05:29:18.468 - OS8104 Driver-debug: MOST message parsed: {“type”:1,“sourceAddrHigh”:1,“sourceAddrLow”:0,“fBlockID”:1,“instanceID”:1,“fktID”:0,“opType”:1,“telID”:0,“telLen”:0,“data”:{“type”:“Buffer”,“data”:[0,0,0,0,0,0,0,0,0,0,0,0]}}

PiMOST looped into the CD changer using optical splitter cable and then got these messages. How can the PiMOST present itself as a SOurce for the Audi MMI in order to inject audio using the parameters like nodeaddress etc?

2

Awesome! good to see it working on an Audi. I’ve got a video that I never got round to uploading that shows you how to do it. I will dig it out and upload it

1 Like
3

Hi Rhys,

Thanks for your reply and support! Just a couple of quick questions while we wait for the video:

  1. In your setup, did you enable or disable the reg.bSDC1_SPDIF_DIS bit in the OS8104 RegisterConfig.ts?

  2. What sample rate value shall I use in config.json - 44 (for 44.1kHz) or 48?.
    I’m currently testing with 44.1kHz and using ‘44’, but not getting audio.

Thanks again, looking forward to that video!

4

I just use the default register values that SocketMost writes to the chip, spdif is not used so I suspect it is disabled but I would have to check. Either way non of the registers should need changing.

For the json, 44 or 48khz is not currently used, it’s there for future purposes when it can function as a master, however for now aslong as the jumper is set for legacy mode it does not matter about 44 vs 48khz as the locking source is the MOST network.

For the HAT version to begin getting audio a few steps needs to happen

  1. Disconnect current amplifier sink
  2. Alloc channels for the PiMost to stream to
  3. Connect amplifier sink the PiMost channels

The video covers it, and at that point if the audio is all set up correct as per the GitHub instructions, it should then work, the PiMost should appear as an audio device is raspbian

Thanks

Rhys

5

Thank you! Please let me know once you upload the video! I’m able to disconnect the existing sink. Now when CD plays there is no audio from amplifier -

  1. Disconnect:

printf ‘{
“eventType”:“sendControlMessage”,
“targetAddressHigh”:5,
“targetAddressLow”:71,
“fBlockID”:34,
“instanceID”:1,
“fktID”:274,
“opType”:2,
“data”:[1]
}’ | socat -u - UNIX-SENDTO:/tmp/SocketMost.sock

result:

06:28:56.013 - OS8104 Driver-debug: MOST message parsed: {“type”:0,“sourceAddrHigh”:5,“sourceAddrLow”:71,“fBlockID”:34,“ins tanceID”:1,“fktID”:274,“opType”:12,“telID”:0,“telLen”:1,“data”:{“type”:“Buffer”,“data”:[1,0,0,0,0,0,0,0,0,0,0,0]}}

  1. Then SocketMost to stream to sink 1:

printf ‘{
“eventType”:“stream”,
“sourceAddrHigh”:6,
“sourceAddrLow”:16,
“fBlockID”:0,
“instanceID”:0,
“sinkNr”:1
}’
| socat -u - UNIX-SENDTO:/tmp/SocketMost.sock

result:
06:32:32.576 - OS8104 Driver-info: stream request, sourceAddressHigh: 0x6 sourceAddressLow: 0x10 fBlockID: 0x0 instanceID: 0x0 sinkNr: 0x1
06:32:32.577 - OS8104 Driver-info: running allocate
06:32:32.581 - OS8104 Driver-debug: setting allocate check
06:32:32.582 - OS8104 Driver-debug: waiting for allocate
06:32:32.585 - OS8104 Driver-debug: message transmitted interrupts
06:32:32.587 - OS8104 Driver-debug: alloc result available
06:32:32.591 - OS8104 Driver-info: connection label: 4
06:32:32.592 - OS8104 Driver-debug: allocate response: {“loc1”:4,“loc2”:5,“loc3”:6,“loc4”:7,“cl”:4,“eventType”:“allocResult”,“answer1”:“ALLOC_GRANT”,“freeChannels”:32}
06:32:32.592 - OS8104 Driver-info: allocResults: {“loc1”:4,“loc2”:5,“loc3”:6,“loc4”:7,“cl”:4,“eventType”:“allocResult”,“answer1”:“ALLOC_GRANT”,“freeChannels”:32}
06:32:32.593 - SocketMost-info: alloc result from os8104
06:32:32.596 - OS8104 Driver-debug: message sent interrupt
06:32:32.604 - OS8104 Driver-info: alloc done setting MRT
06:32:32.605 - OS8104 Driver-info: setting MRT
06:32:32.606 - OS8104 Driver-debug: {“loc1”:4,“loc2”:5,“loc3”:6,“loc4”:7,“cl”:4,“eventType”:“allocResult”,“answer1”:“ALLOC_GRANT”,“freeChannels”:32}
06:32:32.640 - OS8104 Driver-debug: message transmitted interrupts
06:32:32.643 - OS8104 Driver-debug: message sent interrupt
06:32:32.717 - OS8104 Driver-info: connecting sink
06:32:32.719 - OS8104 Driver-info: connecting target sink: sourceAddress: 0x610 fBlockID: 0 instanceID: 0x0 sinkNr: 0x1 location: [0x4, 0x5, 0x6, 0x7]
06:32:32.727 - OS8104 Driver-debug: pimost unmuting source

pi@raspberrypi:~/SocketMost/examples $ speaker-test -Dhw:CARD=PiMost,DEV=0 -c2 -r44100 -FS16_LE -t sine -l1

speaker-test 1.2.4

Playback device is hw:CARD=PiMost,DEV=0
Stream parameters are 44100Hz, S16_LE, 2 channels
Sine wave rate is 440.0000Hz
Rate set to 44100Hz (requested 44100Hz)
Buffer size range from 8 to 131072
Period size range from 4 to 65536
Using max buffer size 131072
Periods = 4
was set period_size = 32768
was set buffer_size = 131072
0 - Front Left
1 - Front Right
Time per period = 3.018905

But I still dont hear audio :frowning: I’m using Alsa:
pi@raspberrypi:~/SocketMost/examples $ aplay -l
**** List of PLAYBACK Hardware Devices ****
card 0: PiMost [PiMost], device 0: bcm2835-i2s-dit-hifi dit-hifi-0 [bcm2835-i2s-dit-hifi dit-hifi-0]
Subdevices: 1/1
Subdevice #0: subdevice #0

Am I missing something?

6

Ah, sending the events via terminal and printf, that’s a cool way of doing it!

Yeah you are missing fblockId and instanceid on the stream message. This should match the amplifier aswell

7

The address should also match the amplifier, the same values as the disconnect message

8

Hi Rhys,

Just wanted to say a huge thank you for this amazing project! SocketMost worked brilliantly and I’ve successfully managed to get audio streaming to my Audi’s amplifier!

After a lot of exploration, here are the final working steps:

  1. Disconnect the original CD sink:

printf ‘{
“eventType”: “sendControlMessage”,
“targetAddressHigh”: 5,
“targetAddressLow”: 71,
“fBlockID”: 34,
“instanceID”: 1,
“fktID”: 274,
“opType”: 2,
“data”: [1]
}’ | socat -u - UNIX-SENDTO:/tmp/SocketMost.sock

  1. Allocate a new stream for PiMost:

printf ‘{
“eventType”: “stream”,
“sourceAddrHigh”: 6,
“sourceAddrLow”: 16,
“fBlockID”: 0,
“instanceID”: 0,
“sinkNr”: 1
}’ | socat -u - UNIX-SENDTO:/tmp/SocketMost.sock

  1. Connect PiMost to the amplifier sink:

printf ‘{
“eventType”: “sendControlMessage”,
“targetAddressHigh”: 5,
“targetAddressLow”: 71,
“fBlockID”: 34,
“instanceID”: 1,
“fktID”: 273,
“opType”: 2,
“data”: [1, 0, 4, 5, 6, 7]
}’ | socat -u - UNIX-SENDTO:/tmp/SocketMost.sock

Best regards,
Ajaz.

9

Amazing, thanks Ajaz! Out of curiousity, what are you plans?

Thanks for the info!

Rhys

10

Thanks again, Rhys!

I’m from India, and I’ve recently left my full-time job at Cisco as Data Network Engineer, to pursue my passion in automotive electronics/Audio. I’m not a developer by title, but I’m an enthusiast who loves to dig deep, figure things out, and get projects working.

This particular project was driven by a personal need as my car didn’t have an AUX input or any way to stream audio, so I took this on as a challenge to stream AirPlay audio directly via MOST.

I’m also working on a few related commercial automotive projects: a line output converter with a mixer input, a USB DAC module for car audio, and an Android Auto wireless adapter that I’m hoping to bring to market initially in India.

I really admire your work and would love to stay in touch or even collaborate someday. If you’re open to it, is there a we could connect, maybe over chat or a platform you prefer?