Looking at this code again (now that I have more time)... where to begin?
First, there's the high-level question of what you're really trying to accomplish here. From the comments and code, it seems you're trying to record a small audio clip to your SD card, and then play it over and over in a loop once per second. I'm going to write the rest of this message based on that assumption....
The first major problem is "sound0" is a AudioPlayMemory object, which plays a sound clip from the internal Teensy memory. Your code isn't even compiling, because you're trying to get an internal memory player to play from the SD card. AudioPlayMemory can't do that. Instead, you need to use AudioPlaySdRaw.
Again from a high-level perspective, a huge problem is you're not using the
design tool. You really should. That's where all the documentation exists. With the design tool, you can see the various players and what capabilities each one offers.
The design tool automatically generates the connection objects for you. Even if you understand them, getting all 4 parameters correct is an error prone process for humans. Even I get them messed up sometimes, and I ought to know since I designed all this stuff. Use the design tool. It will save you from mistakes like the connections you've defined with inputs where outputs should be, and vise-versa. I'm not going to write more about manually creating connections. Use the design tool!!!
Your collection of objects is also illogical. The design tool won't always save you from making something senseless, but at least it will make the incoherence visually apparent. In this system, you've got two I2S output objects. Perhaps "i2s1" was meant to be an input? You've got that connected to the record queue, which is trying to connect 2 objects that take input together. The design tool won't let you draw such connections, and because the visual arrangement makes things clear, you probably won't even try to do such things. Without the design tool, you have no cues in the code to detect these sorts of problems.
Use the design tool. I put a tremendous amount of work into adapting the Node-Red code for exactly these reasons. Even I make syntactic mistakes without the design tool... and I'm the guy who created this syntax!
Back in the code specifics, another problem is you're opening the file in read only mode. You can't write any data that way! If you change this, please be aware the Arduino SD library defaults to appending data when you open in write mode. If you want to overwrite the file, you need to also seek to the beginning after opening in write mode.
After opening, your code checks if the file was able to be opened, which is good. But then your check only does queue1.begin(). After the check, your code does a bunch of other stuff with the file and the queue, regardless of whether the file was properly opened.
Again, looking at this from a higher-level perspective, my guess is you're probably not indenting your code well, which leads to mis-reading it and misunderstanding which things it will conditionally do. And again, there's automated tools to help. In Arduino, click the
Tools > Auto Format menu. This will automatically indent your code properly. These types of errors will become very easy to see with proper indenting.
Back in the small but critical details, there's a conditional test for (queue1.available() >= 2). This test is done only once, right after the queue has started collecting audio data. At that point, odds are pretty much zero that 2 blocks of audio will be available in the queue. For this to work, you need to structure your code to wait and repeat the check until it becomes true.
After trying to write the data, which of course will fail since the file is read-only, and can't happen anyway because of the single too-soon check for queued data, your code isn't calling queue.end(). That's a huge problem, on top of that conditional code never running. These queue objects give you great power to access the high speed audio data. They automatically queue up data, so if your code has high latency (like waiting for the SD card), you don't lose data. But the queues will rapidly fill with audio and exhaust all the memory you allocated with AudioMemory(60). If you're going to ignore the queue, you *MUST* use queue1.end() to stop it from trying to store up more arriving audio data. Once it quickly consumes all the memory, you can't do anything. Even the play object won't be able to play, because the library won't be able to get any memory to move data to the I2S output.
Stepping back once again from these low-level details, one final high-level issue is the extremely short time from of only 512 bytes. That's only 5.8 ms of sound. I probably shouldn't even use the word "sound" for such a short clip, since it's well under the time frame for human cognition of much more than a click or pop. Even if you resolve all these other technical problems, only 5.8 ms is going to be terribly frustrating to hear any results. Ordinary speech and even composed music regularly contain segments where several milliseconds are meaningless, so many attempts will capture "nothing" even when a signal is present. Even detecting a pitch is unlikely with such a short clip. You probably need about 10 times longer just to capture enough for recognition of a tone or a recognizable syllable or fragment of a spoken word.