(Topic ID: 179619)

Rebuilding sound for DataEast & WPC using a pi

By steve45

7 years ago


Topic Heartbeat

Topic Stats

  • 2,042 posts
  • 124 Pinsiders participating
  • Latest reply 38 days ago by Ashram56
  • Topic is favorited by 144 Pinsiders

You

Linked Games

Topic Gallery

View topic image gallery

20230816_111929 (resized).jpg
20230816_111238 (resized).jpg
20230816_111216 (resized).jpg
20230816_111301 (resized).jpg
IMG_6421 (resized).jpg
IMG_6420 (resized).jpg
2023-03-27_18-06-16 (resized).png
IMG_8790 (resized).JPG
rev-3.8-board (resized).jpg
C7BECF85-6A35-49A4-9C0C-611A6E059682 (resized).png
49C01E99-89EB-40E0-8790-5284A9D5CE12 (resized).jpeg
8B5C3740-485C-4518-B3F8-75DECB3FE0F2 (resized).jpeg
F484B39F-E731-4EA6-AF15-EDA85E40774D (resized).jpeg
6A8ECF6B-5C7C-4DB0-9B57-78787F299920 (resized).jpeg
224F7226-27C1-4E5B-8240-13940876411D (resized).jpeg
IMG_9634 (resized).JPG
There are 2,042 posts in this topic. You are on page 29 of 41.
#1401 3 years ago
Quoted from Ashram56:

robotworkshop
One suggestion I would have to determine whether TiltAudio interprets things differently with regards to altsound format parsing is simply to run VPX with the same table, with PinMame sound mode set to 1 (if I recall correctly, might be set to 2).
If it's identical you can then proceed to look at Pinmame source code

Maybe I'm missing something but does VPX and PinMame emulate the Tilt Audio board? If so I can see where that can provide some insight.

Even if it does that still only would cover how VPX and PinMame work with the soundsets. The actual implementation could vary and be slightly different in the Tilit Audio firmware.

I deal with this kind of issue all the time. Hitting the same API's and retrieving the same data sets yet iOS and Android developers have their own thoughts on how to parse and process that payload. Everyone thinks they are doing it the same yet there are occasional slight differences to track down and resolve. Too many times have I run into projects and there ends us being a difference in what everything thinks it is doing vs what it is actually doing. Whether is is a mobile app parsing the data or an emulator or firmware it comes down to ensuring everyone handles the same data the same way.

What I am trying to find out is explicitly how the Tilt Audio firmware implements and parse the soundset data from an altsound csv file. Unless I am totally off base it can only come from the Tilt Audio code to verify how it is doing it.

#1402 3 years ago
Quoted from Robotworkshop:

However I have run into roadblocks that just trade one problem for another without an actual solution. I just suggested something that I think would help. It's up to the owners of the Tilt Audio source whether they want to consider it or not.

To me this still sounds quite vague. What problem are you trying to solve? What roadblocks?

Quoted from Robotworkshop:

Does Tilt Audio embed and use the pinmame source as part of the project to decode the audio?

no, no code shareing.

Quoted from Robotworkshop:

I'd also like to know why Tilt Audio appended on some additional parameters to each of the lines and what they mean. If someone can point to any references in this thread or online I'll be glad to read up on it.

TILT!Audio appends GROUP, SHAKER, SERIAL, PRELOAD and STOPCMD. I though the meaning of these should be quite obvious:

GROUP: just the grouping criteria: music, voice, sfx, ...
SHAKER: shaker sequencer for direct shaker control refers exactly to shaker field in UI
SERIAL: serial command refers exactly to shaker field in UI
PRELOAD: a per sound override whether or not a sound gets preloaded on start
STOPCMD: leave that one to you guys

None of them make really sense in VPIN altsound, thats why these are not present their. In general the altsound format is open in that way that unknown columns should simply ignored. So an enriched CSV from TILT!Audio will still play on VPIN pinmame.

Br Steve

#1403 3 years ago

Robotworkshop

Altsound format was originally developer for VPX and Pinmame, it's not emulating TiltAudio. However the format itself is identical, so by reading you can understand what parameters are taken into account and how.

To adress your concern about implementation discrepancy (and there could be), as a starting point you could look at whether you encounter the same issues with VPX+Pinmame (if I recall not honoring some parameters in the CSV file ?).

If you do find the same behaviour, your starting point can therefore indeed be PinMame source to understand the limitations
If you don't, then this means indeed there is a different implementation/parsing in TiltAudio firmware, which would give a reference point

Regards

#1404 3 years ago

Thanks for the explanations! I was pretty sure about the extra setting for group but you never know. Good to get confirmation.

#1405 3 years ago

Well, I am happy to say I now have 3 working 3.0 cards.

I ordered my PCBs fron JLCPCB with the 3 SMDs presoldered.

Using the BOM from https://oshwlab.com/steve45/tiltaudio I chose these ICs (LCSC part numbers in parentheses) :

74LVC138 : Nexperia 74LVC138AD,118 (C6061)
74LVC00 : Texas Instruments/TI SN74LVC00ADRG4 (C7802)
74LVC754 : Nexperia 74LVC574AD,118 (C6097)

On all 3 boards I then had issues with wrong sounds, extra sounds etc. as described in previous posts.

I then got the exact part numbers from Steve :

74LVC138 : Texas Instruments/TI SN74LVC138ADR (C7816)
74LVC00 : Nexperia 74LVC00AD,118 (C6044)
74LVC754 : Nexperia 74LVC574AD,118 (C6097)

As you can see, 2 of the part numbers were different - but all chips were 74LVC series.

I ordered the 138 and 00 chips and had them changed by a professional.
Now all cards work as they should - no more wrong sounds, no extra sounds.

steve45 : So it seems the WPC interface/bus part is very picky about parts - perhaps this should be reflected in the BOM ?

Can someone tell me what the exact differences are between the chips I chose first and the ones Steve has used ?

#1406 3 years ago

That is excellent news! If you want to read up on the different 74 series logic families there is a good write up here:

https://en.wikipedia.org/wiki/7400-series_integrated_circuits

A lot of the differences are in the thresholds for what is considered a logic 0 or logic one and that gets a bit more interesting considering the interfacing of 5V parts on the MPU with the 3.3V logic for the Raspberry Pi. There are also considerations like fanout but I've run into that more often when an IC has to drive multiple inputs of other chips.

I'll have to check on what parts are included on the V3.0 kit when I get it.

For a deeper dive would need to pull down the data sheets for each of those parts and compare them side by side.

#1407 3 years ago
Quoted from Robotworkshop:

That is excellent news! If you want to read up on the different 74 series logic families there is a good write up here:
https://en.wikipedia.org/wiki/7400-series_integrated_circuits
A lot of the differences are in the thresholds for what is considered a logic 0 or logic one and that gets a bit more interesting considering the interfacing of 5V parts on the MPU with the 3.3V logic for the Raspberry Pi. There are also considerations like fanout but I've run into that more often when an IC has to drive multiple inputs of other chips.
I'll have to check on what parts are included on the V3.0 kit when I get it.
For a deeper dive would need to pull down the data sheets for each of those parts and compare them side by side.

Yep, different families have different properties, that is not unexpected.
But here all chips were in the same family - 74LVC – Low voltage – 1.65–3.3 V and 5 V tolerant inputs, < 5.5 ns at 3.3 V, < 9 ns at 2.5 V.
Which is why I do not understand why the boards did not work with the chips I ordered ... but do with the ones Steve used in his kit.

#1408 3 years ago
Quoted from Zigzagzag:

Yep, different families have different properties, that is not unexpected.
But here all chips were in the same family - 74LVC – Low voltage – 1.65–3.3 V and 5 V tolerant inputs, < 5.5 ns at 3.3 V, < 9 ns at 2.5 V.
Which is why I do not understand why the boards did not work with the chips I ordered ... but do with the ones Steve used in his kit.

Probably because of the different voltage levels 3.3V and 5V and some of the difference manufacturers may tolerate that better. Also, depending on the source of the parts they may not exactly be what is labeled. I've seen remarked parts, etc. If I want to have a better chance of getting parts that are actually what they are supposed to be I'll get them from Digikey or Mouser. I've gotten remarked chips and fakes from other vendors so that is always a possibility.

#1409 3 years ago
Quoted from Zigzagzag:

Well, I am happy to say I now have 3 working 3.0 cards.
I ordered my PCBs fron JLCPCB with the 3 SMDs presoldered.
Using the BOM from https://oshwlab.com/steve45/tiltaudio I chose these ICs (LCSC part numbers in parentheses) :
74LVC138 : Nexperia 74LVC138AD,118 (C6061)
74LVC00 : Texas Instruments/TI SN74LVC00ADRG4 (C7802)
74LVC754 : Nexperia 74LVC574AD,118 (C6097)
On all 3 boards I then had issues with wrong sounds, extra sounds etc. as described in previous posts.
I then got the exact part numbers from Steve :
74LVC138 : Texas Instruments/TI SN74LVC138ADR (C7816)
74LVC00 : Nexperia 74LVC00AD,118 (C6044)
74LVC754 : Nexperia 74LVC574AD,118 (C6097)
As you can see, 2 of the part numbers were different - but all chips were 74LVC series.
I ordered the 138 and 00 chips and had them changed by a professional.
Now all cards work as they should - no more wrong sounds, no extra sounds.
Steve45 : So it seems the WPC interface/bus part is very picky about parts - perhaps this should be reflected in the BOM ?
Can someone tell me what the exact differences are between the chips I chose first and the ones Steve has used ?

Well, that is good news! Looks like thats probably my issue too. Now, do I order new 3.0 boards or try to rework my 2.5d boards. I guess the question is, are those the same chips needed for the 2.5d boards or did they change?

#1410 3 years ago
Quoted from BrewNinja:

Well, that is good news! Looks like thats probably my issue too. Now, do I order new 3.0 boards or try to rework my 2.5d boards. I guess the question is, are those the same chips needed for the 2.5d boards or did they change?

I think some of it may depend on what games you are going to use them in. If it is a Bally/Williams game then I think the extra bus terminating resistors on the V3.0 board would help. I ordered one of those to try in Dr Who. Older board that I have is being re-worked for use in a Data East.

#1411 3 years ago

Anyone put together an actual BOM for the 3.0 boards? Might as well order some new ones.

Alternatively, steve45 can you give us a list of actual part numbers? It should help tremendously in making sure people order the correct things and they work as intended.

#1412 3 years ago

So Ive been poking at the BOM. I need help with a few things and want to confirm a few.

Confirm:
RN1,RN2 4609H-101-472LF‎
RN3,RN4,RN5 4610X-101-470LF
B1 GBU406

Unknown:
R1,R2,R3
R4,R5
C4,C5,C6
L1,L2,L3,L4,L5,L6
C7,C8,C9,C10,C11,C12

I couldnt find FRAME1 anywhere in the files, not sure what that is.

I have links for the random stuff and part numbers for everything else. Hopefully Steve can either just share all the part numbers or at least confirm the first 3 and give part numbers for the other 5.

#1413 3 years ago

Anyone else have installed the license but still get "please register " ?

2021-02-28 19:17:08.301 INFO RasPiSnd [main] [despi.c:950] TILT!Audio starting, version 1.33, serial: 1234, on: Raspberry Pi 3 Model B Plus Rev 1.3
2021-02-28 19:17:08.530 INFO RasPiSnd [verifyKey] [crypt.c:229] trying to load key from /boot/data/1234.key
2021-02-28 19:17:08.568 INFO RasPiSnd [verifyKey] [crypt.c:249] license verified capabilities 0x01

#1414 3 years ago
Quoted from BrewNinja:

R1,R2,R3
R4,R5
C4,C5,C6
L1,L2,L3,L4,L5,L6
C7,C8,C9,C10,C11,C12

While there is "maybe" something about special choice if the decoder logic, this for sure does not apply to these. r1-r5 are just 10k resistors (r3 only if used with DSP). c4-6 are just decoupling caps ca. 220nF, L1-6 together with C7-12 are LC filters for HF noise that may come out of the digital amps.
The LC filters can even left out and replaced by a simple wire if you don't care about HF noise. (see e.g. https://www.maximintegrated.com/en/design/technical-documents/app-notes/6/624.html).
At the moment I use 700Ω @ 100MHz Ferrite Beads (LCSC #C59501) and 200pF ±10% 50V Ceramic (LCSC# C254072).

#1415 3 years ago
Quoted from Zigzagzag:

TILT!Audio starting, version 1.33, serial: 1234, on: Raspberry Pi 3

This is not a real serial number as far as I can tell.
can you maybe post cat /proc/cpuinfo of you pi.

#1416 3 years ago
Quoted from steve45:

This is not a real serial number as far as I can tell.
can you maybe post cat /proc/cpuinfo of you pi.

I masked the serial number - but I suspect this might be because I have a license without LUA - but LUA was enabled in the config.
Can this be the case ?

#1417 3 years ago
Quoted from steve45:

While there is "maybe" something about special choice if the decoder logic

This is now verified with card #4 out of 5.
It worked first time, even with one of the 4k7 resistor networks missing (waiting for parts).
This in contrast with the previous 3 cards that all had exactly the same errors.

To be precise, here "my" 74LVC00 and 74LVC138 were replaced by "yours" before assembling the rest.

I will put together card #5 in the upcoming days.

#1418 3 years ago

(double post)

#1419 3 years ago
Quoted from Zigzagzag:

This is now verified with card #4 out of 5.
It worked first time, even with one of the 4k7 resistor networks missing (waiting for parts).
This in contrast with the previous 3 cards that all had exactly the same errors.
To be precise, here "my" 74LVC00 and 74LVC138 were replaced by "yours" before assembling the rest.
I will put together card #5 in the upcoming days.

Would be interesting if you could replace the components back to "yours" one at a time to see if one in particular is responsible.

#1420 3 years ago
Quoted from RobF:

Would be interesting if you could replace the components back to "yours" one at a time to see if one in particular is responsible.

It is the combination of the address decoder 00 and 138. You should be safe when you have both of one series from one manufacturer.

#1421 3 years ago
Quoted from lucky1:

It is the combination of the address decoder 00 and 138. You should be safe when you have both of one series from one manufacturer.

Interesting you should say that, since the parts that Steve uses (and that I have success with) are from 2 different manufacturers ?

Not working :

74LVC138 : Nexperia 74LVC138AD,118 (C6061)
74LVC00 : Texas Instruments/TI SN74LVC00ADRG4 (C7802)

Working :

74LVC138 : Texas Instruments/TI SN74LVC138ADR (C7816)
74LVC00 : Nexperia 74LVC00AD,118 (C6044)

#1422 3 years ago

You can run serial media server on the same Pi as the TiltAudio card uses : https://pinside.com/pinball/forum/topic/new-creature-holo-mod-for-cftbl/page/3#post-6170514

#1423 3 years ago

Is there any way to let a certain sound play even though a stop command is sent ?

Right now, I am missing the end music snippet on CFTBL.
When the ball goes down the drain, sound id 16 is played - but is cut short by the immediately following stop music command.
It looks weird when the bonus is added to the score with no sound.

I have tried moving sound id 16 to different categories, but the result stays the same.

2021-01-24 00:05:12.921 DEBUG isr wpc [wdenInterrupt] [pincom.c:346] wpc cmd 00000 016 0x10 00010000 len: 1
2021-01-24 00:05:12.921 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:1895] wpcSoundHandler cmd: 0x10 0x00 0x00 0x00, id: 16
2021-01-24 00:05:12.921 DEBUG SndServi [getVolumeForSample] [sdl_sound.c:1035] getVolumeForSample: sample->gain: 50, gainByType: 30, res: 16
2021-01-24 00:05:12.921 DEBUG SndServi [playSample] [sdl_sound.c:1586] playing sample 16:7 vol: 50->16 'voice' 'main_theme' on channel 0
2021-01-24 00:05:12.921 DEBUG SndServi [doCheckDucking] [sdl_sound.c:529] sample starts playing on channel -1
2021-01-24 00:05:12.999 DEBUG isr wpc [wdenInterrupt] [pincom.c:346] wpc cmd 00000 127 0x7f 01111111 len: 1
2021-01-24 00:05:12.999 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:1895] wpcSoundHandler cmd: 0x7f 0x00 0x00 0x00, id: 127
2021-01-24 00:05:12.999 DEBUG SndServi [handleSoundByTypeWithIdx] [sdl_sound.c:1676] stop cmd detected 127, stopping music
2021-01-24 00:05:12.999 DEBUG SndServi [doCheckDucking] [sdl_sound.c:531] channel 0 has finished
2021-01-24 00:05:13.000 DEBUG isr wpc [wdenInterrupt] [pincom.c:346] wpc cmd 00000 125 0x7d 01111101 len: 1
2021-01-24 00:05:13.000 DEBUG isr wpc [soundWpcHandler] [sdl_sound.c:1895] wpcSoundHandler cmd: 0x7d 0x00 0x00 0x00, id: 125
2021-01-24 00:05:13.000 DEBUG SndServi [handleSoundByTypeWithIdx] [sdl_sound.c:1676] stop cmd detected 125, stopping music

#1424 3 years ago
Quoted from Zigzagzag:

Is there any way to let a certain sound play even though a stop command is sent ?

Right now, I am missing the end music snippet on CFTBL.
When the ball goes down the drain, sound id 16 is played - but is cut short by the immediately following stop music command.
It looks weird when the bonus is added to the score with no sound.

I the recent firmware version (1.34rcXX) I changed the way stop commands are handled in the config, but it feels that this not a good idea in any case. So if you are on 1.33 and older, you can simply remove the 0x7D and 0x7F from the stop command list and it should work.

#1425 3 years ago

steve45 that did the trick, thank you.

Super exclusive ad from the Pinside Marketplace!
#1426 3 years ago
Quoted from steve45:

I the recent firmware version (1.34rcXX) I changed the way stop commands are handled in the config, but it feels that this not a good idea in any case. So if you are on 1.33 and older, you can simply remove the 0x7D and 0x7F from the stop command list and it should work.

I just built my board and have it in my funhouse, only issue so far is the music stops, in looking at the logs I'm seeing a 0x7F stop command. So where is the stop command list? I've poked around the files and not seeing anything.

Found the answer in the web interface config screen, under the sound settings. Looked right past the stop commands there.

#1427 3 years ago

steve45 I have some feature requests :

1) Low-pass filter on the cabinet amp input. I assume most people place a sub/bass speaker in the cabinet. Having sounds/frequencies over 200 Hz or so coming out of the bottom of the pinball sounds weird to me and I feel it muddies up the stereo speaker sound from the front speakers. One could of course put a passive crossover in front of the speaker, but the cost of a low pass in the amp section is lower than the cost of a passive crossover component. If the frequency could be adjustable that would be awesome.

2) Could we have a short fadeout on stop command instead of abrupt muting of the sound ? Again, the music snippets playing when CFTBL counts up the bonus points get cut off hard. Having a (configurable) fadeout or a "ignore stop command for this sound" setting would help.

#1428 3 years ago

... and card #5 works fine on first try, again with the SMD chips same as come with the kit from steve45

#1429 3 years ago
Quoted from Zigzagzag:

1) Low-pass filter on the cabinet amp input. I assume most people place a sub/bass speaker in the cabinet. Having sounds/frequencies over 200 Hz or so coming out of the bottom of the pinball sounds weird to me and I feel it muddies up the stereo speaker sound from the front speakers. One could of course put a passive crossover in front of the speaker, but the cost of a low pass in the amp section is lower than the cost of a passive crossover component. If the frequency could be adjustable that would be awesome.

The optional DSP instead of the DAC provides a fully configurable 2.1 output. You can even use Sigma Studio to make your own programs with features like dynamic bass for your system.
https://tiltaudio.com/tag/2-0/

#1430 3 years ago
Quoted from lucky1:

The optional DSP instead of the DAC provides a fully configurable 2.1 output. You can even use Sigma Studio to make your own programs with features like dynamic bass for your system.
https://tiltaudio.com/tag/2-0/

Wow ! That sounds amazing =D

Guess I'll have to upgrade ....

#1431 3 years ago
Quoted from Zigzagzag:

Could we have a short fadeout on stop command instead of abrupt muting of the sound ? Again, the music snippets playing when CFTBL counts up the bonus points get cut off hard. Having a (configurable) fadeout or a "ignore stop command for this sound" setting would help

That's an easy one. I put it on the list for upcoming releases.

#1432 3 years ago

steve45 How would one go about combining altsound.csv and config.raspisnd ?
I have concatenated both files into one single and called it config.raspisnd - is this the correct way to do it ?

#1433 3 years ago
Quoted from Zigzagzag:

How would one go about combining altsound.csv and config.raspisnd ?
I have concatenated both files into one single and called it config.raspisnd - is this the correct way to do it ?

No, not correct. There is no combing of both. config.raspisnd belongs to old sound pack format with directories, altsound.csv belongs to the new altsound format. Either or, not both

#1434 3 years ago

If we wanted to convert the old style sounds to the new altsound then we should just copy all the sounds in one directory (ensuring names are unique) and then create a new csv file as the index map the sounds and how they should be played?

#1435 3 years ago
Quoted from steve45:

No, not correct. There is no combing of both. config.raspisnd belongs to old sound pack format with directories, altsound.csv belongs to the new altsound format. Either or, not both

Ok, so how would one go about combining the gain/volume etc. settings from altsound.csv with the necessary config.raspisnd ?
I could not get the Java application for converting mentioned here before to work on Ubuntu.

#1436 3 years ago
Quoted from Zigzagzag:

Ok, so how would one go about combining the gain/volume etc. settings from altsound.csv with the necessary config.raspisnd ?
I could not get the Java application for converting mentioned here before to work on Ubuntu.

What exactly do you want to combine? What setting from config.raspisnd with what in the csv.

In the altsound.csv simple each sound effect has its own setting? Don't understand, what you want to achieve?

#1437 3 years ago
Quoted from Robotworkshop:

If we wanted to convert the old style sounds to the new altsound then we should just copy all the sounds in one directory (ensuring names are unique) and then create a new csv file as the index map the sounds and how they should be played?

Yes exactly, but why would you do that. After that conversion it is just the same sound pack as before, just a different format.

#1438 3 years ago
Quoted from steve45:

Yes exactly, but why would you do that. After that conversion it is just the same sound pack as before, just a different format.

I thought using the altsound csv file is supposed to offer more control over how sounds are played.

I was planning ahead for my Dr Who. If a sound pack was in the old format and had a scrambled or encoded it would need a new key like the csv file so tilt audio would know how to play them. The sounds seemed to be there. I asked the creator of the 13 doctors mix if he minded if I used that and he said it was fine. I thought if I had to spend time making that index then I may be better to move the sounds and switch to a csv file.

If there are short cuts I can try please let me know.

#1439 3 years ago
Quoted from Tiberium:

That's why I would like someone to be able to modify the rom so that this check is not done.

With regards to this issue, has anyone identified how the check is being done (using a Logic analyzer or such), ie which signals are being used and how ?

#1440 3 years ago
Quoted from steve45:

What exactly do you want to combine? What setting from config.raspisnd with what in the csv.
In the altsound.csv simple each sound effect has its own setting? Don't understand, what you want to achieve?

Ok, maybe I misunderstand.

I have config.raspisnd containing only soundfile mappings, something like this :

006a 0669745621
00ab 2443549466
00ab 3687932183
00ab 2443549466

... etc.

I have altsound.csv something like this :

"ID","CHANNEL","DUCK","GAIN","LOOP","STOP","NAME","FNAME"
"0x006a", 1, 10, 60, 0, 0, "monkey_brain_award", "Monkey Brain Award Reorchestrated.ogg"
"0x00ab", 1, 10, 60, 0, 0, "jackpot", "Jackpot 2.ogg"
"0x00ab", 1, 10, 60, 0, 0, "jackpot", "Jackpot.ogg"

So - I want to (need to ?) use the soundfile mappings from config.raspisnd and also the channel/duck/gain/loop etc. from altsound.csv

If I place both altsound.csv and config.raspisnd in the sound set directory, it seems TiltAudio doesn't read config.raspisnd - only altsound.csv

How do I achieve this ?

#1441 3 years ago
Quoted from Zigzagzag:

So - I want to (need to ?) use the soundfile mappings from config.raspisnd and also the channel/duck/gain/loop etc. from altsound.csv

If I place both altsound.csv and config.raspisnd in the sound set directory, it seems TiltAudio doesn't read config.raspisnd - only altsound.csv

How do I achieve this ?

I actually don't really get the point. You are asking a lot of internals without even having a problem. Why?

Of course for an altsound soundpack all information is covered in the csv itself, no need to read config.raspisnd.

So again: What problem are you trying to solve? To state "I want to achieve that it reads this file and that file" is not a valid problem from a users perspective.

#1442 3 years ago
Quoted from Ashram56:

With regards to this issue, has anyone identified how the check is being done (using a Logic analyzer or such), ie which signals are being used and how ?

There is some information out there. You can just look at the freeWPC source code or the pinmame source to get an understanding, what is happening in the boot sequence. It basically always comes down to the bus interface is bi-directional and some boot code expects a type code and a version from the sound board. If the sound board keeps quiet while booting you get an "sound board interface error".

But I want to reassure (did I mention it here in this forum?) that I'm working on a solution. So for the ones that are really affected by this (only a few roms actually do the check) , stay tuned there will be an improvement on this.

Br Steve

#1443 3 years ago
Quoted from steve45:

I actually don't really get the point. You are asking a lot of internals without even having a problem. Why?
Of course for an altsound soundpack all information is covered in the csv itself, no need to read config.raspisnd.
So again: What problem are you trying to solve? To state "I want to achieve that it reads this file and that file" is not a valid problem from a users perspective.

I want a third party scrambled soundset to use settings from altsound.csv

#1444 3 years ago
Quoted from Robotworkshop:

I thought using the altsound csv file is supposed to offer more control over how sounds are played.

I was planning ahead for my Dr Who. If a sound pack was in the old format and had a scrambled or encoded it would need a new key like the csv file so tilt audio would know how to play them. The sounds seemed to be there. I asked the creator of the 13 doctors mix if he minded if I used that and he said it was fine. I thought if I had to spend time making that index then I may be better to move the sounds and switch to a csv file.

The obvious difference is that all meta data (gain, ducking, preload ...) is PER SOUND, not only per Category. Also altsound as it's coming from open course vpinmame (virtual pinball community) it is not in any sense "encrypted", just very clear line by line:

Sound Command ID as is it received from the MPU, sound filename, name of sound effect, ....

-> easy to read / write, easy to understand.

The basic playback control (volumes, which one does stop which, when to resume background music ) is all in all the same. It is the same sound engine (TILT!Audio).

Also here: "What problem are you trying to solve?" Please talk more in "feature requests" not in "what would be theoretically be possible in altsound, that is not possible in old format".

#1445 3 years ago
Quoted from steve45:

There is some information out there. You can just look at the freeWPC source code or the pinmame source to get an understanding, what is happening in the boot sequence. It basically always comes down to the bus interface is bi-directional and some boot code expects a type code and a version from the sound board. If the sound board keeps quiet while booting you get an "sound board interface error".
But I want to reassure (did I mention it here in this forum?) that I'm working on a solution. So for the ones that are really affected by this (only a few roms actually do the check) , stay tuned there will be an improvement on this.
Br Steve

Cool, good to know, thanks. I was otherwise going to work on a version using a CPLD replacing the logic blocks between the header and the RPI, but since you're already on it.

Cheers

#1446 3 years ago
Quoted from steve45:

Also here: "What problem are you trying to solve?" Please talk more in "feature requests" not in "what would be theoretically be possible in altsound, that is not possible in old format".

The problem I am trying to solve is that there are alternative sound sets made by individual authors who don’t mind if they are used on a sound card like Tilt Audio. All the audio assets are there. However whatever index file exists is in binary and not in a format Tilt Audio understands. That needs to be recreated. Can either make one from scratch leaving all the sounds in their folders or just move them all to a common folder and create a csv file instead. That seemed a better since it seems that would ultimately provide more options for tweaking the way sounds are played. At least in my case it isn’t that I need to use the altsound csv format. It’s that I need to create that index and if I have to go through the effort why not use the format that should be superior.

#1447 3 years ago
Quoted from Robotworkshop:

The problem I am trying to solve is that there are alternative sound sets made by individual authors who don’t mind if they are used on a sound card like Tilt Audio. All the audio assets are there. However whatever index file exists is in binary and not in a format Tilt Audio understands. That needs to be recreated. Can either make one from scratch leaving all the sounds in their folders or just move them all to a common folder and create a csv file instead. That seemed a better since it seems that would ultimately provide more options for tweaking the way sounds are played. At least in my case it isn’t that I need to use the altsound csv format. It’s that I need to create that index and if I have to go through the effort why not use the format that should be superior.

This is what I am trying to achieve as well.

#1448 3 years ago
Quoted from Robotworkshop:

individual authors who don’t mind if they are used on a sound card like Tilt Audio.

Do you have their permission to use the soundsets for tiltaudio ?

#1449 3 years ago
Quoted from lucky1:

Do you have their permission to use the soundsets for tiltaudio ?

I am interested in using the 13 Doctors mix and had asked the person who created it if it was ok to use. He is very active on the Dr Who thread on Pinside. Unless there is something I missed as long as I ask the person who did all the work on the original sound set it should be fine.

#1450 3 years ago
Quoted from Robotworkshop:

I am interested in using the 13 Doctors mix and had asked the person who created it if it was ok to use. He is very active on the Dr Who thread on Pinside. Unless there is something I missed as long as I ask the person who did all the work on the original sound set it should be fine.

Correct !

Promoted items from Pinside Marketplace and Pinside Shops!
5,000 (Firm)
Machine - For Sale
Gilroy, CA
$ 9.95
$ 10.00
Playfield - Protection
UpKick Pinball
 
$ 259.99
Cabinet - Toppers
Lighted Pinball Mods
 
$ 45.99
Lighting - Interactive
Lee's Parts
 
7,500
Machine - For Sale
Matthews, NC
$ 15.95
Playfield - Toys/Add-ons
ULEKstore
 
$ 1,059.00
Flipper Parts
Mircoplayfields
 
From: $ 9,499.00
Pinball Machine
Paradise Distribution
 
8,000 (Firm)
Machine - For Sale
Reno, NV
$ 18.00
Lighting - Led
Mitchell Lighting
 
$ 29.95
Lighting - Led
Mitchell Lighting
 
$ 1.25
Lighting - Led
Mitchell Lighting
 
$ 250.00
Lighting - Interactive
Professor Pinball
 
$ 17.99
Eproms
Matt's Basement Arcade
 
$ 18.95
Eproms
Pinballrom
 
$ 1.00
Pinball Machine
Pinball Alley
 
From: $ 33.00
Gameroom - Decorations
Rocket City Pinball
 
$ 19.95
Lighting - Led
Mitchell Lighting
 
$ 50.00
Playfield - Protection
Duke Pinball
 
From: $ 9.99
From: $ 9.00
Playfield - Toys/Add-ons
UpKick Pinball
 
Wanted
Machine - Wanted
Louisville, KY
$ 259.99
Cabinet - Toppers
Lighted Pinball Mods
 
$ 49.99
Cabinet - Toppers
Lighted Pinball Mods
 
Hey modders!
Your shop name here
There are 2,042 posts in this topic. You are on page 29 of 41.

Reply

Wanna join the discussion? Please sign in to reply to this topic.

Hey there! Welcome to Pinside!

Donate to Pinside

Great to see you're enjoying Pinside! Did you know Pinside is able to run without any 3rd-party banners or ads, thanks to the support from our visitors? Please consider a donation to Pinside and get anext to your username to show for it! Or better yet, subscribe to Pinside+!


This page was printed from https://pinside.com/pinball/forum/topic/rebuilding-sound-for-de-jurassic-park-using-a-pi/page/29?hl=robotworkshop and we tried optimising it for printing. Some page elements may have been deliberately hidden.

Scan the QR code on the left to jump to the URL this document was printed from.