That video seems to use the phrases "synchronous" and "asynchronous" communication in a bit of a different sense than I've usually seen. In a way, there seems to be some internal logic to it, but it's mixing matters up enough to be confusing.
If we talk about hardware signals, and someone mentions "asynchronous" transmission, what comes to mind is the common UART serial port related to RS232. (Though I understand RS232 actually defines connectors and voltages, not the parts interesting here, so there's likely room to argue about correct naming). Of course things like USB, SPI and SATA are also serial, but those aren't what we mean here.
UART communication basically amounts to sending bits of some length determined by the clock on the transmitter, and hoping the receiver gets the reception right. That is, the receiver has to be expecting data with that particular bit rate, and must be able to produce a clock that runs at the same speed as the transmitters clock. The transmitter and receiver aren't explicitly synchronized (within the definition of the low-level signalling, anyway), hence asynchronous communication.
With an ugly ASCII-art, a simplified UART transmission where the sender puts a new bit on the data line on each rising edge of its own clock, and the receiver samples the data line once on each falling edge of its clock. Here the receiver's clock is running fast (or the sender's is running slow), and it will eventually read garbled data when sampling point goes off the bit edges.
sender clock (internal)
| +--------------+ +--------------
<---bit 0--------------------><---bit 1-------------------->
^ ^ sampling points
| +------------+ +-------------
receiver clock (internal)
That's opposed, to say SPI, or "Serial Peripheral Interface", where the hardware contains both a data line (two, really), and an explicit clock line, and the timing of the data bits are in relation to that shared clock. Hence, the transmitter and receiver are synchronized, via that clock signal.
Here, there is only one clock, used both by the sender and the receiver:
| +----------+ +----------
<---bit 0-------------><---bit 1------------>
+-- sampling points --+
Between the two options of having no clock signal and having a dedicated clock line, is embedding the clocking on the signal itself. Regardless of the way it's done, the point is to ensure enough transitions on the data line to let the receiver correct for any clock drift against those transitions. That's mostly used by higher-speed interfaces and is likely to be more complex. Ethernet (with 8b/10b encoding and others), and USB (with bit stuffing) fall into this category.
What that video appears to be talking about at the point you refer to (around 11:44), is not really the hardware interface, but instead the software side. The way he describes "asynchronous" transmission is basically to have the CPU run in a busyloop, repeatedly asking the peripheral if there's more data to read, and processing that data when there is.
The slide in the video at 11:36 literally says:
- The CPU has to check the status of the I/O module to know when the device is ready to transfer the next word
- While the CPU is checking whether the I/O module is ready, it cannot do anything else.
That's what I would call polling in a busy loop, and that's not really well suited for any I/O.
For serious applications, you very much want to avoid having the CPU do that, exactly because it means the CPU can't do useful work at the same time. You could have a lower-level device do the same on hardware, but that's much less of a problem, since a purpose-built device can probably do it with less power consumption, because it's simpler than a full CPU, and optimally would run with a lower clock rate.
The opposite for polling would usually be an interrupt-driven peripheral, where instead of the CPU repeatedly asking the peripheral if it's ready, the CPU can do other work in the meanwhile, and the peripheral comes to tell when it has new data. (What the CPU does after that is a matter for the operating system and the applications.) The video does actually mention interrupt-driven data transfer too, at 23:17 or so.
Polling by the CPU can be usefully done for slow devices (esp. ones that don't provide interrupts), like physical buttons on a microcontroller, or the old PC-style joystick port. But even then, it's not done by having the CPU run a busy loop, but by having a timer interrupt the CPU, which then manually interrogates the peripheral.
(USB uses polling on the protocol level, but that's done by the USB controller and the device, it's not something the main CPU needs to be involved with.)
The funny thing is that the video also uses UART as an example of asynchronous data transmission (at around 15:03), but neglects to mention that this time it's talking about the hardware, and not the interface between the CPU and the peripheral.
It also says:
The devices are asynchronous at the level of bytes, but are synchronous at the level of bits within the bytes
... which is pretty much opposite to how I would describe it. The UART receiver synchronizes to the start of the byte (the starting edge of the start bit), but there's nothing to synchronize the lengths of the individual bits.
Note that those are two separate things: polling vs. interrupts on the CPU aren't tied to synchronous vs. asynchronous communication on the hardware. It's entirely possible to have data from both UART (async) and SPI (sync) come to the CPU via interrupts. Or, if you want to do things the stupid way, to have the CPU poll the peripheral, which is again possible for both UART and SPI.