Hacker Newsnew | past | comments | ask | show | jobs | submit | LogicCowboy's commentslogin

HP's Halo conferencing system had several studio quality cameras that would change the video feed based on who was talking. There were also specially placed mics on the conference table to keep audio crisp. The video quality was impressive, however you had the same issues that you have with current web-cam based systems. Eye-contact was non-existent. While the camera placement was above the middle-top of the LCD screen, you'd never feel like the person was making eye-contact with you unless they looked directly at the camera. I had several team meetings in Halo rooms, and for the time, it was the next best thing to having a meeting in person. It also worked well for groups of 4 on each side of the link.

From watching the video, Google's conferencing setup is creating a 3D rep of the people talking and adjusting rendered view based on where the participants are seated. This is blending AR with videoconferencing. It would be interesting to see how their conferencing system works with multiple-people on each side. I know the video had a mother and baby in one segment, however is the 3D rendering based on the eye-level of the main participants?


> Eye-contact was non-existent.

Potentially a solved problem, just fix it in post. :)

https://www.zdnet.com/article/windows-10-microsoft-finally-l...

I wonder how well it works, and how much latency (if any) it adds to the feed.

I'm also sad it isn't rolled out more generally, a very strange feature to lock behind a small-ish volume hardware product.


This is ARM's definite response to RISC-V. As people develop their FPGA products, they will have to decide what their long term target is. If the intent is to eventually turn the code into an ASIC, RISC-V maybe the economically more sensible solution since there is no licensing costs there. However they will have to be patient with the toolchain. If the idea if the code will only be a pet project, wouldn't benefit from RISC's customization abilities, or long term is expected to use an ARM core, this is definitely the right pick. The ARM toolchain being more mature is a draw for many hardware developers.

I'm definitely very interested in trying a project with either RISC-V or ARM.


Equally by offering this for Xilinx, it makes them more palatable over Altera offerings (owned by Intel). So a very tactile move on many levels.

But as an end user, I like competition like this, as long as there is competition tomorrow.


The release of the M1 is not just for Xilinx.

ARM is releasing the M1 for Xilinx, Altera, Actel FPGAs. These are firm (i.e. technology mapped) cores adapted for each FPGA family.

Here for example is the documentation for the Altera version. Note that it sports the Altera Avalon bus interface which would not be used in a Xilinx design.

https://developer.arm.com/docs/dui0395/latest/introduction/a...

And here is the announcement/information about the M1 core for Actel/Microsemi FPGAs:

https://soc.microsemi.com/products/ip/search/detail.aspx?id=...


This article from EE Times lists all FPGA vendors as well as EDA vendors supporting the M1 cores:

https://www.eetimes.com/document.asp?doc_id=1303843


There are lots of other FPGAs that are still available for RISC-V to target that are precluded from this announcement.

ARM used to sue anyone trying to make an ARM clone and now this. Great news for RISC-V. At least one if not two low end FPGA manufacturers will be shipping a fabric with hard blocks supporting RISC-V.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: