Save Audio ADC samples in SD Card in STM32
I use DMA to save data in SD card

Are you sure about this? I don't see anything remotely related to DMA in your code.
You need to configure DMA for circular buffer and use HAL_ADC_Start_DMA() to begin regular transfer of ADC data into buffer.
Then you need to process HAL_ADC_ConvHalfCpltCallback() and HAL_ADC_ConvCpltCallback() to write accumulated data into file.
Furthermore, you should not use f_open(), f_lseek() and f_close() on every write operation, they take an awful amount of time. Open file once at the beginning and keep writing data blocks until the end, then close file once. This way you have much better chance of keeping up with the incoming data flow.
Checking myBytes after f_write() call is also a good idea - you need to know if something goes wrong.
Finally, using f_printf() instead of f_write() may or may not be more efficient for writing bytes as text, but it sure will make your program more readable.
UPDATE
Please, don't use answers to ask questions. Nevertheless, I'll answer your new questions here.

because of sample rate is so important for me that have specific and
constant value, I use timer to implement that. because of this I don't
use DMA for ADC

If sample rate is so important for you, why do you use heavy HAL timer code plus your own, instead of configuring ADC for continuous scan with fixed sampling rate and DMA for immediate transfer of results without software delays? You cannot beat hardware timing for sampling, so this approach just does not make any sense.

But I use DMA for SD card and my main guidance for that, is this tutorial...

That is another problem, right here. That tutorial uses DMA in worst possible way - they start DMA transaction and then enter a &quot;while&quot; loop until it completes (in BSP_SD_WriteBlocks_DMA function), effectively making DMA transfer into a blocking call.
Unfortunately that is a result of the way FatFS is written. Note, that this actually works more or less OK in preemptive mode RTOS, as other threads can continue working. For non-RTOS applications, however, it does not look good.
A lot of people are trying to come up with non-blocking ports or alternative implementations of FatFS, like AsyncFatFS for example. You can do a research and try some of them, I don't have any specific implementation I can endorse.