Yeah there are some tools that allows you to covert C code into running on a FPGA, but this does NOT remove the need to know a HDL language and general FPGA workflows.
The C code that you put in has to be written with the FPGA in mind and needs some knowledge on how the whole thing works. Otherwise you can end up filling a giant FPGA completely full using just a few lines of code or have code that runs a lot slower than it should.
What these C code converter tools are useful for is when the FPGA needs to be programed to do a very complex task as they essentially provide an extra layer of abstraction. Very useful for things like hardware video decoders/encoders that are already complicated to understand in C code. But if you are able to break your problem down into a bunch of D flipflops and computational logic then its easier and more efficient to simply express it in the actual HDL language.
Lucky for you that a lot of audio DSP operations are mostly just putting the samples trough some math equations in a certain order and this is easy to convert into HDL code. That is provided you can get the math to work with fixed point numbers since floating point is not very FPGA friendly due to the complex logic needed to do math with it. Since these things are often used for DSP work means that a lot of FPGA vendors might have some ready to go modules of common DSP functions. These might be things like FIR and IIR filters, NCO signal generators, upsamplers/downsamplers, FFT etc...
Also FPGAs are not always better than CPUs. They are a bit like GPUs in a PC where they are great at doing a simple(but possibly also very long) task over and over on a lot of data. While they are not very good at complex tasks that involve making a lot of decisions and taking different routes trough the procedure all the time. As an example a FPGA can implement a SD card interface pretty nicely where you can give it commands like "Write 0x55 0x45 0x45... to sector 465", it has to do the same thing every time to execute that. But if you wanted to do something like "Append decimal 1234 onto file log.csv" then you are going to have a hell of a time teaching a FPGA to do it and use a lot of resources(Both inside the chip and in hours of your work). Such a task involves first finding the FAT32 filesystem on the card, then navigating to the directory, then finding the log.csv in a file table, allocating a new sector to that file, writing the data to that sector, updating the file table entry and finally closing the file. This is very easy to do with a CPU however so in such a case you would be best off to include one in the design where the "Write sector" functionality would be left in the FPGA while the filesystem is handled by the CPU that gives commands to the FPGA on what sectors to read and write. In this case you use a external microcontroler that's connected to the FPGA over some sort of bus or you build a softcore CPU inside the FPGA(Some FPGAs even have built in CPUs) and run compiled C code on that.
One neat trick when using an external MCU/CPU with a FPGA is to use a MCU that has support for external SRAM memory (A lot of decent ARM MCUs have this). If you connect these external memory pins to the FPGA then you can have the FPGA act like its a SRAM chip, except that these memory locations are actually reading/writing to hardware registers inside the FPGA. As a result you can build peripherals inside the FPGA and memory map them into the MCU so that they are used just like the built in peripherals. This makes the FPGA sort of like a south bridge in a PC or a sort of coprocessor.