The SD library can use either SPI or SDIO, depending on whether your code uses SD.begin(cspin) or SD.begin(BUILTIN_SDCARD).
SPI and SDIO are completely independent, so if you have a SD card on SDIO it should not interfere with access to a memory chip on SPI.
But with either Teensy 4.0 or 4.1, adding a SRAM chip on SPI probably doesn't make a lot of sense. The existing code in the audio library only supports one SRAM chip which is relatively small and fairly slow. It is only usable for audio delay. That made more sense with Teensy 3.0, 3.1, 3.2 where the on-chip RAM is limited (16K or 64K) which left little RAM for audio delay. On Teensy 4.x where you have 1024K of RAM, incurring so much overhead just to add a slow 128K RAM chip probably doesn't make sense.
If you really need more RAM, adding the
PSRAM chip(s) to Teensy 4.1 is definitely the way to go. The chip has 8192K and uses 4 bit I/O at a much higher clock speed. The on-chip hardware maps the PSRAM chip as if were real memory, so you're not going through the SPI library. The Cortex M7 cache is used to speed up most types of access, so while the PSRAM isn't nearly as fast as on-chip RAM, you only suffer that slower speed for cache misses. For many types of access, it gives pretty good performance (but some there are some exceptions like huge FIR filters where the cache helps much less). If 8BM isn't enough, you can solder 2 of them and they're accessible as 16MB memory. The best part is you can just create variables and arrays with EXTMEM or call extmem_malloc() and then use the variables the same way as any others in normal on-chip memory. With slow SPI, all must be done by special code calling the SPI library functions.
But to answer your original question, if you really are using a slow 23LC1024 (or similar) RAM chip on the SPI pins, switching the SD card from SPI to SDIO will not cause a problem. If anything, it may help, because the SPI pins won't be need some of the time for SD.
