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: FEAT. RQ.: bypass channel to foobar audio_chunk interface (Read 5380 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

FEAT. RQ.: bypass channel to foobar audio_chunk interface

Would it be possible to add an option in advanced preferences that would add a bypass channel to foobar audio_chunk interface skipping DSP chain and Volume control?

The idea is that this channel should directly deliver unchanged sound data to output device (like WASAPI or ASIO) without going into DSP and Volume Control chain. This way it will be possible to add true DoP mode without needing to resort to ASIO or WASAPI Proxies.

I've no idea about the innards of Foobar so if this is against any TOS or policy I'm sorry and please any admin move it to the bin or delete it. Ditto if it belongs in another sub forum.

Cheers

FEAT. RQ.: bypass channel to foobar audio_chunk interface

Reply #1
Sorry to bump but.... no one? Peter?

FEAT. RQ.: bypass channel to foobar audio_chunk interface

Reply #2
Not sure what you mean "foobar audio_chunk interface", doesn't sound like it's what I refer to by "audio_chunk".

If passing unaltered PCM stream to the device is what you want, you can already do that by setting volume to max, disabling ReplayGain and DSP. What else do you want, a single checkbox to toggle all of volume/RG/DSP with one click? Sounds like it will generate "volume control doesn't work" and "equalizer doesn't work" tech support traffic.
Microsoft Windows: We can't script here, this is bat country.

FEAT. RQ.: bypass channel to foobar audio_chunk interface

Reply #3
Thanks Peter but it is not about PCM but rather about DSD (DoP= DSD over PCM -> DoP).

It would seem switching off Volume/RG/DSP is not enough because all kinds of visualizers (VU meter, oscilloscope, etc) will still work and interpret DoP stream as PCM data. What's needed is to add set_data_type(t_data_type data_type) method to the audio_chunk interface. So it can be called like p_chunk.set_data_type(RAW_AUDIO_DATA) for each audio_chunk of DSD sound data to request that this chunk needs to be delvered to output device unchanged and witout any processing by visualizers like VU meter and others.

The setting entry could be well hidden in advances preferences so those not in the know wouldn't mess with. Maybe name it "DoP Bitsreaming enable" or something similar.

Cheers

FEAT. RQ.: bypass channel to foobar audio_chunk interface

Reply #4
audio_chunk was specifically designed to carry PCM data only and will not be changed to carry anything else; using it to carry any data other than plain PCM is broken by design. Further than that, it cannot possibly be changed without breaking component compatibility.
Microsoft Windows: We can't script here, this is bat country.

FEAT. RQ.: bypass channel to foobar audio_chunk interface

Reply #5
Thanks for the explanation.

Pity it is not possible, it could have been the first and only free DSD player for Windows, much like MPD in the Linux world. There are a few players out there capable of DSD (DoP or DSD over ASIO) but all are commercial products.

Cheers

FEAT. RQ.: bypass channel to foobar audio_chunk interface

Reply #6
Likely only ASIO is capable of carrying DSD anyway. foo_input_sacd includes its own ASIO output component just for this purpose, it may even work for you.

FEAT. RQ.: bypass channel to foobar audio_chunk interface

Reply #7
Note that visualizations are incapable of modifying the audio stream.
The way a vis works is that it occasionally asks for copies of chunks of decoded audio which it may analyze and generate awesome looks from.
The only plugins that mutate audio streams are DSPs, and if you disable all the things that Peter mentioned, nothing will be mutilated.

Now, if your problem is that visualizations are showing "the wrong thing" by not knowing that the PCM stream they get isn't PCM, well, that's a different problem, and it should not have anything to do with playback.
Stay sane, exile.

FEAT. RQ.: bypass channel to foobar audio_chunk interface

Reply #8
Likely only ASIO is capable of carrying DSD anyway. foo_input_sacd includes its own ASIO output component just for this purpose, it may even work for you.


foo_dsd_output does indeed work fine with ASIO compatible drivers but for WASAPI/KS ones a 2nd proxy (ASIO4All) has to be thrown in. It works but it isn't the most elegant solution (DSD decoder -> foo_dsd_asio -> ASIO4All -> WASAPI/KS driver) . When I started this thread, before learning DSD was ruled out by design, I was just wondering if something better was possible as now there are some very affordable USB->I2S+DSD adapters becoming available (there is one going for 39€ in a GB at DIYA) that allow for designing very cheap DIY universal DACs. 

Note that visualizations are incapable of modifying the audio stream.
The way a vis works is that it occasionally asks for copies of chunks of decoded audio which it may analyze and generate awesome looks from.
The only plugins that mutate audio streams are DSPs, and if you disable all the things that Peter mentioned, nothing will be mutilated.

Now, if your problem is that visualizations are showing "the wrong thing" by not knowing that the PCM stream they get isn't PCM, well, that's a different problem, and it should not have anything to do with playback.


Thing is, as Peter pointed out, it does not work with DoP neither on ASIO nor on WASAPI/KS, even if it looks like it should.

FEAT. RQ.: bypass channel to foobar audio_chunk interface

Reply #9
so, hi

would like to revive this topic.
can i please, again, ask why this is not possible?
could you not create a second audio chunk that outputs PCM, and if DoP protocol is used, it also outputs a flag, that lets the entire system know that it is not PCM data that is being transported?
so no visualization, and no DSP takes place.

or is DSD not in the interest of foobar? i always saw this player as the cleanest solution possible for windows to play hires files.
i actually started a thread to inquire if Peter was wiling to implement DoP protocol in WASAPI. seems the best way to go..

FEAT. RQ.: bypass channel to foobar audio_chunk interface

Reply #10
what the hell.

why is visualisation important to this. the vis manager/streams just sees audio_chunks, they don't alter them in any way.